[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Compiling lua for uClinux
- From: "Guido Sohne" <guido@...>
- Date: Fri, 7 Jul 2006 06:25:59 +0000
I found the source of the problem. The compiler flags were not quite right ...
Here's what worked for compiling Lua for my target hardware.
--- lua-5.1.1/src/Makefile 2006-03-22 00:41:49.000000000 +0000
+++ /Users/guido/Projects/development/sunyard/lua-5.1.1/src/Makefile
2006-07-06 23:40:15.000000000 +0000
@@ -5,22 +5,51 @@
# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT =======================
# Your platform. See PLATS for possible values.
-PLAT= none
+PLAT= uclinux
+
+# vendor toolchain
+MACHINE= 68000
+CPU= c68000
+
+UCLINUX= /usr/local/uClinux
+
+MYLDPATH= -L$(UCLINUX)/lib/uClibc/. \
+ -L$(UCLINUX)/lib/uClibc/lib \
+ -L$(UCLINUX)/lib/libm \
+ -L$(UCLINUX)/lib/libnet \
+ -L$(UCLINUX)/lib/libdes \
+ -L$(UCLINUX)/lib/libaes \
+ -L$(UCLINUX)/lib/libpcap \
+ -L$(UCLINUX)/lib/libssl \
+ -L$(UCLINUX)/lib/libcrypt_old \
+ -L$(UCLINUX)/lib/libsnapgear++ \
+ -L$(UCLINUX)/lib/libsnapgear \
+ -L$(UCLINUX)/lib/zlib
+
+MYDEFS= -DCONFIG_LINEO -Dlinux -D__linux__ -Dunix
-D__uClinux__ -DEMBED -D__USE_BSD
+MYINCS= -I$(UCLINUX)/lib/uClibc/include -I$(VENDOR) -I$(UCLINUX)
+
+MYCFLAGS= $(MYDEFS) $(MYINCS) -fno-builtin -msep-data
+MYLDFLAGS= $(CFLAGS) -Wl,-elf2flt -Wl,-move-rodata -nostartfiles
$(UCLINUX)/lib/uClibc/lib/crt0.o $(MYLDPATH)
CC= gcc
-CFLAGS= -O2 -Wall $(MYCFLAGS)
+CFLAGS= -m$(MACHINE) -Os -g -fomit-frame-pointer -m$(CPU)
-Wall $(MYCFLAGS)
AR= ar rcu
RANLIB= ranlib
RM= rm -f
-LIBS= -lm $(MYLIBS)
-
-MYCFLAGS=
-MYLDFLAGS=
-MYLIBS=
+LIBS= $(MYLIBS) -lc -lm
# == END OF USER SETTINGS. NO NEED TO CHANGE ANYTHING BELOW THIS LINE =========
-PLATS= aix ansi bsd generic linux macosx mingw posix solaris
+PLATS= aix ansi bsd generic linux macosx mingw posix solaris uclinux
LUA_A= liblua.a
CORE_O= lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o
llex.o lmem.o \
@@ -110,6 +140,9 @@
solaris:
$(MAKE) all MYCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN" MYLIBS="-ldl"
+uclinux:
+ $(MAKE) all MYCFLAGS="-DLUA_USE_UCLINUX $(MYCFLAGS)"
+
# list targets that do not create files (but not all makes understand .PHONY)
.PHONY: all $(PLATS) default o a clean depend echo none
Following diff specifies uclinux as a Lua target platform and isolates
lua into /opt/lua-5.1.1 so that it can be easily tarballed and copied
over to the target machine (my vendor makes /var writeable but
/usr/local is not)
--- lua-5.1.1/Makefile 2006-06-02 10:53:38.000000000 +0000
+++ /Users/guido/Projects/development/sunyard/lua-5.1.1/Makefile
2006-07-03 04:40:37.000000000 +0000
@@ -5,13 +5,13 @@
# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT =======================
# Your platform. See PLATS for possible values.
-PLAT= none
+PLAT= uclinux
# Where to install. The installation starts in the src directory, so take care
# if INSTALL_TOP is not an absolute path. (Man pages are installed from the
# doc directory.)
#
-INSTALL_TOP= /usr/local
+INSTALL_TOP= /opt/lua-$V
INSTALL_BIN= $(INSTALL_TOP)/bin
INSTALL_INC= $(INSTALL_TOP)/include
INSTALL_LIB= $(INSTALL_TOP)/lib
@@ -22,10 +22,10 @@
# How to install. You may prefer "install" instead of "cp" if you have it.
# To remove debug information from binaries, use "install -s" in INSTALL_EXEC.
#
-INSTALL_EXEC= $(CP)
-INSTALL_DATA= $(CP)
-#INSTALL_EXEC= $(INSTALL) -m 0755
-#INSTALL_DATA= $(INSTALL) -m 0644
+#INSTALL_EXEC= $(CP)
+#INSTALL_DATA= $(CP)
+INSTALL_EXEC= $(INSTALL) -m 0755
+INSTALL_DATA= $(INSTALL) -m 0644
# Utilities.
CP= cp
@@ -37,7 +37,7 @@
# == END OF USER SETTINGS. NO NEED TO CHANGE ANYTHING BELOW THIS LINE =========
# Convenience platforms targets.
-PLATS= aix ansi bsd generic linux macosx mingw posix solaris
+PLATS= aix ansi bsd generic linux macosx mingw posix solaris uclinux
# What to install.
TO_BIN= lua luac
The following diff reduces Lua's default resource consumption, sets
our Lua code to not be backwards compatible with prior Lua versions,
and defines the uclinux platform as a Posix environment (has isatty(),
mkstemp(), popen() and ulongjmp()) and also turns off shared library
functionality.
--- lua-5.1.1/src/luaconf.h 2006-04-10 18:27:23.000000000 +0000
+++ /Users/guido/Projects/development/sunyard/lua-5.1.1/src/luaconf.h
2006-07-03 04:44:42.000000000 +0000
@@ -44,8 +44,9 @@
#define LUA_DL_DYLD /* does not need extra library */
#endif
-
-
+#if defined(LUA_USE_UCLINUX)
+#define LUA_USE_POSIX
+#endif
/*
@@ LUA_USE_POSIX includes all functionallity listed as X/Open System
@* Interfaces Extension (XSI).
@@ -333,14 +334,14 @@
** CHANGE it to undefined as soon as your programs use only '...' to
** access vararg parameters (instead of the old 'arg' table).
*/
-#define LUA_COMPAT_VARARG
+#undef LUA_COMPAT_VARARG
/*
@@ LUA_COMPAT_MOD controls compatibility with old math.mod function.
** CHANGE it to undefined as soon as your programs use 'math.fmod' or
** the new '%' operator instead of 'math.mod'.
*/
-#define LUA_COMPAT_MOD
+#undef LUA_COMPAT_MOD
/*
@@ LUA_COMPAT_LSTR controls compatibility with old long string nesting
@@ -355,7 +356,7 @@
** CHANGE it to undefined as soon as you rename 'string.gfind' to
** 'string.gmatch'.
*/
-#define LUA_COMPAT_GFIND
+#undef LUA_COMPAT_GFIND
/*
@@ LUA_COMPAT_OPENLIB controls compatibility with old 'luaL_openlib'
@@ -363,7 +364,7 @@
** CHANGE it to undefined as soon as you replace to 'luaL_registry'
** your uses of 'luaL_openlib'
*/
-#define LUA_COMPAT_OPENLIB
+#undef LUA_COMPAT_OPENLIB
@@ -432,7 +433,7 @@
** arbitrary; its only purpose is to stop infinite recursion before
** exhausting memory.
*/
-#define LUAI_MAXCALLS 20000
+#define LUAI_MAXCALLS 5000
/*
@@ -442,7 +443,7 @@
** functions. This limit is arbitrary; its only purpose is to stop C
** functions to consume unlimited stack space.
*/
-#define LUAI_MAXCSTACK 2048
+#define LUAI_MAXCSTACK 1024
-- G.
On 6/27/06, Guido Sohne <guido@sohne.net> wrote:
I understand that it may be impossible to get help on this. I would
appreciate it if someone could give me a clue on how to actually track
this down or correct any misunderstanding that I may have as at now.
Please help. Tearing my hair out here.
-- G.
On 6/27/06, Guido Sohne <guido@sohne.net> wrote:
> Dear All:
>
> I'm having the dreaded BINFMT_FLAT: reloc outside program error while
> extending lua. Normally, lua likes to load code as a shared library
> and I'm building this code into the executable instead, so as to get
> around the lack of shared libraries on M68000 hardware.
>
> BINFMT_FLAT: reloc outside program 0x61723a74 (0 -
> 0xffe83214/0x2f720), killing lua!
> BINFMT_FLAT: reloc outside program 0x61723a74 (0 -
> 0xffe83214/0x2f720), killing lua!
>
> I've searched through the list archives trying to track this down.
> I've compiled with -fno-common, increased the stack size all to no
> avail. There was a post earlier about having to rename variables and
> avoiding that with -fno-common etc but that didn't work for me either.
>
> I managed to track down the bug to the code that causes it (a SIGSEGV
> accompanied by the above BINFMT_FLAT error) and hope that I could get
> some help or insight as to what is actually going wrong. I've built
> the same executable on Mac OS X and I've verified that it works there,
> so the problem is isolated to uclinux.
>
> In lua code, we have a luaL_Reg struct which associates a 'library'
> name to a startup function. The startup function is normally supposed
> to be called when the library is dynamically loaded, but once we place
> it in the lualibs struct, then it gets called (preloaded) when lua
> starts up. So far so good.
>
> In the code below LUALIB_API gets defined to extern or
> __declspec(dllimport) or __declspec(dllexport) (for Windows), so for
> our purposes, we can just assume it's extern, since we aren't on
> Windows. Lines marked 0 are part of lua-out-of-the-box and they work
> fine (there are several others like it before that also work ok).
> Lines marked 1 and 2 are my additions, which call the library
> initialization functions.
>
> #define LUA_LOADLIBNAME "package" // 0
> LUALIB_API int (luaopen_package) (lua_State *L); // 0
>
> #define LUA_SOCKLIBNAME "socket.core" // 1
> LUALIB_API int (luaopen_socket_core) (lua_State *L); // 1
>
> #define LUA_MIMELIBNAME "mime.core" // 2
> LUALIB_API int (luaopen_mime_core) (lua_State *L); // 2
>
> Now here is an array of these structs that lua walks through, calling
> each initialization function as it finds it. I have added the lines
> marked 3 to have the library initialization function called. If I
> comment out the lines marked 3, then my executable runs fine. If I
> include those lines, I get the SIGSEGV/BINFMT_FLAT error.
>
> static const luaL_Reg lualibs[] = {
> {"", luaopen_base},
> {LUA_LOADLIBNAME, luaopen_package},
> {LUA_TABLIBNAME, luaopen_table},
> {LUA_IOLIBNAME, luaopen_io},
> {LUA_OSLIBNAME, luaopen_os},
> {LUA_STRLIBNAME, luaopen_string},
> {LUA_MATHLIBNAME, luaopen_math},
> {LUA_DBLIBNAME, luaopen_debug},
> {LUA_SOCKLIBNAME, luaopen_socket_core}, // 3
> {LUA_MIMELIBNAME, luaopen_mime_core}, // 3
> {NULL, NULL}
> };
>
> m68k-elf-objdump -t lua.gdb > lua.dump gives me the following symbol
> information ...
>
> 0003123c l O .data 00000058 lualibs
> 00010cee g F .text 00000028 luaopen_base
> 000164a2 g F .text 00000170 luaopen_package
> 000166c0 g F .text 0000005a luaopen_socket_core
> 0001671c g F .text 00000064 luaopen_mime_core
>
> And running elf2flt with the -v flag gives me the following relocation
> information. Strangely, here the fixups are zero for these symbols and
> we're adding an awfully large offset to the symbol base, aren't we? I
> noticed the BINFMT_FLAT error above had a huge offset (0x61723a74)
> which is very likely much larger than my entire problem. Is this
> normal? Or is that how we are getting to the data segment (where
> lualibs contains the function pointer needing relocation) from the
> text segment (where we are relocating to) in the flat binary?
>
> So I guess my question is why does this work for luaopen_package, but
> not for luaopen_socket_core? ie. How come lua will start fine with
> luaopen_package active but crashes as soon as I introduce *any* of the
> lines marked 3? Am I blowing my stack? I tried increasing stack size
> via an export FLTFLAGS="-v -s 159999" and I still got the same
> problem. Making the stack absurdly large got me a slightly different
> error - "Illegal instruction" ... Adding debug printf's at the entry
> points of the function pointers doesn't result in any output, so
> something is happening as soon as these functions are called, but they
> never actually get called.
>
> RELOC[68]: offset=1b20 symbol=luaopen_base+0xfffef312 section=.text
> size=4 fixup=0 (reloc=0x31240)
> reloc[68] = 0x31240
> RELOC[69]: offset=1b24 symbol=.text+0x2c555 section=.text size=4
> fixup=2c555 (reloc=0x31244)
> reloc[69] = 0x31244
> RELOC[70]: offset=1b28 symbol=luaopen_package+0xfffe9b5e
> section=.text size=4 fixup=0 (reloc=0x31248)
> reloc[70] = 0x31248
> RELOC[71]: offset=1b2c symbol=.text+0x2c54f section=.text size=4
> fixup=2c54f (reloc=0x3124c)
> reloc[71] = 0x3124c
> RELOC[84]: offset=1b60 symbol=luaopen_socket_core+0xfffe9940
> section=.text size=4 fixup=0 (reloc=0x31280)
> reloc[84] = 0x31280
> RELOC[85]: offset=1b64 symbol=.text+0x2c521 section=.text size=4
> fixup=2c521 (reloc=0x31284)
> reloc[85] = 0x31284
> RELOC[86]: offset=1b68 symbol=luaopen_mime_core+0xfffe98e4
> section=.text size=4 fixup=0 (reloc=0x31288)
> reloc[86] = 0x31288
> RELOC[87]: offset=1b74 symbol=.text+0x2c660 section=.text size=4
> fixup=2c660 (reloc=0x31294)
> reloc[87] = 0x31294
>
> I don't really understand what is going wrong here and I'm learning a
> lot more about the lua interpreter and elf2flt than I really need to
> know just to include socket code into my application, so any help
> would greatly appreciated :-) If I'm talking nonsense, then please let
> me know ASAP too! :-)
>
> -- G.
>
