Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JIT] Programs cannot resolve the fstat function #646

Closed
lattner opened this issue Mar 9, 2004 · 7 comments
Closed

[JIT] Programs cannot resolve the fstat function #646

lattner opened this issue Mar 9, 2004 · 7 comments

Comments

@lattner
Copy link
Collaborator

lattner commented Mar 9, 2004

Bugzilla Link 274
Resolution FIXED
Resolved on Jul 01, 2020 11:23
Version 1.0
OS Linux
CC @adamse

Extended Description

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

@lattner
Copy link
Collaborator Author

lattner commented Mar 9, 2004

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

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 9, 2004

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.

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 9, 2004

proposed patch

@lattner
Copy link
Collaborator Author

lattner commented Mar 9, 2004

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

@lattner
Copy link
Collaborator Author

lattner commented Mar 9, 2004

Also RE: the patch, you should add a better comment above the array, and
reference this bug. :)

-Chris

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 9, 2004

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

@adamse
Copy link
Mannequin

adamse mannequin commented Jul 1, 2020

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

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 1, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants