Programs that use the 'fstat' function (such as GNU m4) are failing to work with the JIT, because dlsym is apparently failing on it or something. Here's a small testcase: #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> int main() { struct stat SB; return fstat(1, &SB); } $ llvmgcc test.c -c -o - | lli WARNING: Cannot resolve fn '__main' using a dummy noop function instead! WARNING: Cannot resolve fn 'fstat' using a dummy noop function instead! Note that the __main warning is expected, but the fstat one is not. -Chris
Hrm, I think this is just because libc on our systems is an archive file, and the fstat.o file isn't being linked into the jit. This is problematic, because we have to be able to expose ALL symbols from libc through the JIT... Brian, do you know of any majik that can be used to say 'link this program, but export/require all symbols from archives'? -Chris
I think you were on the right track, but I'm pretty sure this is the linux glibc "libc_nonshared.a" hack biting us on the butt. Observe: 30 zion> cat /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a ) 31 zion> nm /usr/lib/libc_nonshared.a | grep ' T ' 0000000c T __libc_csu_fini 00000000 T __libc_csu_init 00000000 T atexit 00000000 T __stat 00000000 T __fstat 00000000 T __lstat 00000000 T __mknod 00000000 T stat64 00000000 T fstat64 00000000 T lstat64 I have a patch that fixes this in the simple way; i.e., just make sure that *stat and mknod are linked in -- they seem to be the only functions glibc treats specially this way. (Googling for libc_nonshared.a leads me to believe they've treated only these functions in this special way since 1998.) I will post my patch below for your consideration. The other way to solve this would be to teach lli how to grovel through /usr/lib/libc.so and /usr/lib/libc_nonshared.a itself. I think this is a bad idea because, while it would be more general, it would be incredibly complex, and I suspect that the odds of their adding things to libc_nonshared.a are low.
Created attachment 91 [details] proposed patch
> The other way to solve this would be to teach lli how to grovel through > /usr/lib/libc.so and /usr/lib/libc_nonshared.a itself. I think this is a bad > idea because, while it would be more general, it would be incredibly complex, > and I suspect that the odds of their adding things to libc_nonshared.a are low. **SHUDDER** > I'm pretty sure this is the linux glibc > "libc_nonshared.a" hack biting us on the butt. Hrm, I was never even aware of that. :P RE: your patch, I think you should add fstat64 and friends as well. It looks like that is what is killing awk: http://llvm.cs.uiuc.edu/~gaeke/external-tests/gally/2004_03_08_16_50_01/GNU_awk.Test_with_JIT.txt I'm also concerned about making it static. It should probably just be a namespace scope thing, because a even only somewhat decently smart compiler should drop unused static objects. Another way of adding references to these would be to put wrappers into the external functions support from the interpreter. Otherwise, it looks good. :) -Chris
Also RE: the patch, you should add a better comment above the array, and reference this bug. :) -Chris
Thanks for your comments on the patch. The bug should be fixed now. Final patch is here: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040308/012917.html
For future reference here is an updated link to the final patch: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20040308/012917.html