Building Lua with ELLCC This Time With a Twist

In a previous post, I used ELLCC to cross build Lua for the ARM running Linux. Subsequently I’ve done a bit of work to make ELLCC more configurable, and also to handle bare metal compilation more easily. I had a little time on my hands tonight so I thought I’d try out the changes with the latest Lua 5.2.3 version.
First, I modified the lua-5.2.3/src/Makefile to add the following around line 27:

# Start of ELLCC definitions.
PLAT= generic
ELLCC= /home/rich/ellcc
ELLCCBIN= $(ELLCC)/bin/
CC= $(ELLCCBIN)ecc
ELLCCPREFIX= $(ELLCCBIN)ecc-
AR= $(ELLCCPREFIX)ar rcu
RANLIB= $(ELLCCPREFIX)ranlib

TARGET= x86_64-linux-eng
MYCFLAGS= -target $(TARGET)
MYLDFLAGS= -target $(TARGET)
# End of ELLCC definitions.

Then I build for my host system, an x86_64 Linux box:

[~/lua-5.2.3/src] dev% make
/home/rich/ellcc/bin/ecc -O2 -Wall -DLUA_COMPAT_ALL  -target x86_64-linux-eng   -c -o lapi.o lapi.c
...
/home/rich/ellcc/bin/ecc -O2 -Wall -DLUA_COMPAT_ALL  -target x86_64-linux-eng   -c -o linit.o linit.c
/home/rich/ellcc/bin/ecc-ar rcu liblua.a lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o lbitlib.o lcorolib.o ldblib.o liolib.o lmathlib.o loslib.o lstrlib.o ltablib.o loadlib.o linit.o 
/home/rich/ellcc/bin/ecc-ranlib liblua.a
/home/rich/ellcc/bin/ecc -O2 -Wall -DLUA_COMPAT_ALL  -target x86_64-linux-eng   -c -o lua.o lua.c
/home/rich/ellcc/bin/ecc -o lua  -target x86_64-linux-eng lua.o liblua.a -lm  
/home/rich/ellcc/bin/ecc -O2 -Wall -DLUA_COMPAT_ALL  -target x86_64-linux-eng   -c -o luac.o luac.c
/home/rich/ellcc/bin/ecc -o luac  -target x86_64-linux-eng luac.o liblua.a -lm  
[~/lua-5.2.3/src] dev% ./lua
Lua 5.2.3  Copyright (C) 1994-2013 Lua.org, PUC-Rio
> print ("hello")
hello
> 
[~/lua-5.2.3/src] dev% 

So far so good. How about a cross compile?

[~/lua-5.2.3/src] dev% make clean
rm -f liblua.a lua luac lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o lbitlib.o lcorolib.o ldblib.o liolib.o lmathlib.o loslib.o lstrlib.o ltablib.o loadlib.o linit.o  lua.o luac.o
[~/lua-5.2.3/src] dev% make TARGET=arm-linux-engeabi
/home/rich/ellcc/bin/ecc -O2 -Wall -DLUA_COMPAT_ALL  -target arm-linux-engeabi   -c -o lapi.o lapi.c
...
/home/rich/ellcc/bin/ecc -o lua  -target arm-linux-engeabi lua.o liblua.a -lm  
/home/rich/ellcc/bin/ecc -O2 -Wall -DLUA_COMPAT_ALL  -target arm-linux-engeabi   -c -o luac.o luac.c
/home/rich/ellcc/bin/ecc -o luac  -target arm-linux-engeabi luac.o liblua.a -lm  
[~/lua-5.2.3/src] dev% ~/ellcc/bin/qemu-arm lua
Lua 5.2.3  Copyright (C) 1994-2013 Lua.org, PUC-Rio
> print ("hello")
hello
> 
[~/lua-5.2.3/src] dev% 

Now for a real test. How about a bare metal test on the ARM?

[~/lua-5.2.3/src] dev% rm lua
[~/lua-5.2.3/src] dev% make TARGET=arm-elk-engeabi
/home/rich/ellcc/bin/ecc -o lua  -target arm-elk-engeabi lua.o liblua.a -lm  
[~/lua-5.2.3/src] dev%  ~/ellcc/bin/qemu-system-arm -M vexpress-a9 -m 128M -nographic -kernel lua
audio: Could not init `oss' audio driver
unhandled system call (256) args: 1, 268472376, 1610613215, 1610613023, 1207961673, 1241513744
Lua 5.2.3  Copyright (C) 1994-2013 Lua.org, PUC-Rio
> print ("hello")
unhandled system call (175) args: 1, 1241512616, 0, 8, 237792, 0
unhandled system call (174) args: 2, 1241512644, 1241512624, 8, 237792, 0
hello
unhandled system call (174) args: 2, 1241512644, 1241512624, 8, 237792, 0
> 

As described in the previous post, the unhandled system calls are those that haven’t been implemented in ELK yet. In this case, they are

...
#define __NR_rt_sigaction       174
#define __NR_rt_sigprocmask     175
...
#define __NR_set_tid_address    256
...

none of which are needed in my little test. Bare metal Lua. Luanix?

After I had this little bit of excitement, I remembered that I had configured ELK with the task scheduler and system timer. I figured it might be worth a try to see if at least the interrupt driven timer was working. Sure enough:

> print (os.date())
unhandled system call (174) args: 2, 1241512644, 1241512624, 8, 1207961832, 1241512696
unhandled system call (5) args: 276151, 657408, 0, 1, 1241510728, 1241511520
Thu Jan  1 00:07:22 1970
unhandled system call (174) args: 2, 1241512644, 1241512624, 8, 1207961832, 1241512696
> print (os.date())
unhandled system call (174) args: 2, 1241512644, 1241512624, 8, 1207961832, 1241512696
Thu Jan  1 00:07:45 1970
unhandled system call (174) args: 2, 1241512644, 1241512624, 8, 1207961832, 1241512696
> 

Time keeps on ticking. Fun stuff.

Leave a Reply

Your email address will not be published.