RE: LuaJIT 2.0 beta 9 on PPC GCC 4.4.6 uClibc 0.9.29 mpc8248 PowerQuicc II processor

["Solinsky, Jeff - PAL" <Jeff.Solinsky@...>]

Pall, Mike - wrote:
> > luajit: can't resolve symbol '__ashldi3' in lib 'luajit'.
> This is weird, because this is a symbol dependency that GCC
> generates on its own, not something that's used in the source.
> This symbol ought to be part of libgcc. Maybe you need to
> statically link with libgcc?

I tried statically linking with libgcc:
powerpc-mpc8248-linux-uclibc-gcc    -Wl,-E   -o luajit luajit.o libluajit.a -lm -lgcc -ldl

And received the same results about __ashldi3; it is odd that, that is the only internal gcc symbol that appears to be UNDEFINED when I look at the symbols in the luajit using readelf. Maybe the compiler has an issue.. I think the implementation I added of __ashldi3 is correct though, so not worrying about it for now.

> > "Command terminated by signal 4", when trying to execute some
> > lua code with jit enabled.
> This is usually caused by not syncing the D/I-caches after JIT
> machine code generation. The support is in lj_mcode_sync() in file
> lj_mcode.c. You could try to see whether this actually finds the
> VDSO kernel symbol on your installation or whether it bails out to
> the dummy function. I guess I should have made this function raise
> an error instead ...

Very right you are, I added a print to mcode_sync_dummy and saw that
it was falling back to the dummy function.

I realized our file system was missing vdso32.so and the linux-vdso32.so.1 link.  After copying these files from the arch/powerpc/kernel/vdso32 directory I realize there seems to be something inherently wrong with the uClibc linker loading dynamic libraries that have relative addresses.
I received the following error:

luajit: symbol 'TSPC32_TV_SEC': can't handle reloc type 0x3 in lib '/lib/linux-vdso32.so.1'
Segmentation fault

It seems that I need to do something to cause access to the memory to use PIC instructions or the dynamic loader is to stupid to load the libs.

Here is part of the output when doing objdump --reloc on gettimeofday.o,
which is the object file that is part of vdso32.so that has the TSPC32_TV_SEC symbol.
000000b6 R_PPC_ADDR16      TSPC32_TV_SEC
000000ce R_PPC_ADDR16      TSPC32_TV_NSEC
..

I wonder if these linking issues are fixed on newer uClibc versions.
I really don't have the luxury of moving uClibc forward, because we
there are some binaries that need to run on our boards that have
dependencies on uClibc-0.9.29 and going forward breaks binary compatibility.

Trying to see what I need to do to the kernel Makefile or patching the sources to change to PIC access to those addresses.  Apparently it's more than adding fPIC as gettimeofday.o is being compiled with the following:

powerpc-mpc8248-linux-gnu-gcc -m32 -Wp,MD,arch/powerpc/kernel/vdso32/
.gettimeofday.o.d  -nostdinc -isystem /home/atc/opt4/kernelchain/ppc8248-
linux-toolchain/bin/../lib/gcc/powerpc-mpc8248-linux-gnu/4.1.2/include 
-D__KERNEL__ -Iinclude  -include include/linux/autoconf.h -Iarch/ppc 
-Iarch/ppc/include -D__ASSEMBLY__ -Iarch/ppc -Wa,-maltivec -D__VDSO32__ 
-s -fPIC   -c -o arch/powerpc/kernel/vdso32/gettimeofday.o
arch/powerpc/kernel/vdso32/gettimeofday.S

Hoping once I solve this LuaJIT will run successfully.

Thanks,
~ Jeff