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 an attachment (id=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