ERROR: Program used external function 'stat' which could not be resolved!

[edwintorok]

Bugzilla Link	1873
Resolution	FIXED
Resolved on	Jan 03, 2008 01:11
Version	unspecified
OS	Linux

Extended Description

I get this when running the JIT:

/home/edwin/llvm-svn/llvm/Release/bin/lli -force-interpreter=false --disable-core-files Output/clamscan.llvm.bc --debug --no-summary -ddbdir -r inputs/*
ERROR: Program used external function 'stat' which could not be resolved!
/home/edwin/llvm-svn/llvm/Release/bin/lli[0x8cc51b]
/lib/libc.so.6[0x3508432040]
/lib/libc.so.6(gsignal+0x35)[0x3508431fd5]
/lib/libc.so.6(abort+0x110)[0x3508433a30]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::JIT::getPointerToNamedFunction(std::basic_string<char, std::char_traits, std::allocator > const&)+0xf1)[0x5e0c71]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::JIT::getPointerToFunction(llvm::Function*)+0xe1)[0x5e1fb1]
/home/edwin/llvm-svn/llvm/Release/bin/lli[0x5e37b0]
/home/edwin/llvm-svn/llvm/Release/bin/lli[0x5e43f8]
/home/edwin/llvm-svn/llvm/Release/bin/lli[0x4af0be]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::MachineFunctionPass::runOnFunction(llvm::Function&)+0x2c)[0x5c06dc]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x231)[0x87a351]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::FunctionPassManagerImpl::run(llvm::Function&)+0xdc)[0x87a83c]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::FunctionPassManager::run(llvm::Function&)+0x30)[0x87a990]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::JIT::runJITOnFunction(llvm::Function*)+0x38)[0x5e0d68]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::JIT::getPointerToFunction(llvm::Function*)+0x12d)[0x5e1ffd]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocatorllvm::GenericValue > const&)+0x4c)[0x5e104c]
/home/edwin/llvm-svn/llvm/Release/bin/lli(llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::vector<std::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::basic_string<char, std::char_traits, std::allocator > > > const&, char const* const*)+0x382)[0x5eaf92]
/home/edwin/llvm-svn/llvm/Release/bin/lli(main+0x233)[0x4a5463]
/lib/libc.so.6(__libc_start_main+0xf4)[0x350841e1c4]
/home/edwin/llvm-svn/llvm/Release/bin/lli(sinh+0x49)[0x4a4919]
Aborted

Trying to get a bugpoint reduced bytecode ...

[edwintorok]

bugpoint on original testcase takes a long time, however I created a simple testcase:

#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
int main()
{
struct stat buf;
stat("/tmp",&buf);
}

$ llvm-gcc -emit-llvm -c test.c -o test.bc
$ lli test.bc
ERROR: Program used external function 'stat' which could not be resolved!
lli[0x8cc63b]
/lib/libc.so.6[0x3508432040]
/lib/libc.so.6(gsignal+0x35)[0x3508431fd5]
/lib/libc.so.6(abort+0x110)[0x3508433a30]
lli(llvm::JIT::getPointerToNamedFunction(std::basic_string<char, std::char_traits, std::allocator > const&)+0xf1)[0x5e0eb1]
lli(llvm::JIT::getPointerToFunction(llvm::Function*)+0xe1)[0x5e21f1]
lli[0x5e39f0]
lli[0x5e4638]
lli[0x4af1de]
lli(llvm::MachineFunctionPass::runOnFunction(llvm::Function&)+0x2c)[0x5c070c]
lli(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x231)[0x87a491]
lli(llvm::FunctionPassManagerImpl::run(llvm::Function&)+0xdc)[0x87a97c]
lli(llvm::FunctionPassManager::run(llvm::Function&)+0x30)[0x87aad0]
lli(llvm::JIT::runJITOnFunction(llvm::Function*)+0x38)[0x5e0fa8]
lli(llvm::JIT::getPointerToFunction(llvm::Function*)+0x12d)[0x5e223d]
lli(llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocatorllvm::GenericValue > const&)+0x4c)[0x5e128c]
lli(llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::vector<std::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::basic_string<char, std::char_traits, std::allocator > > > const&, char const* const*)+0x352)[0x5ecd32]
lli(main+0x233)[0x4a5583]
/lib/libc.so.6(__libc_start_main+0xf4)[0x350841e1c4]
lli(sinh+0x51)[0x4a4a39]
Aborted

$ bugpoint -run-jit test.bc
...
Emitted bitcode to 'bugpoint-reduced-simplified.bc

[edwintorok]

bugpoint-reduced-simplified.ll

[lattner]

The test works fine for me on darwin/x86. Are you on linux? IF so, it would be interesting to find out why the hack in lib/ExececutionEngine/JIT/Intercept.cpp isn't working (search for 'stat' in that file). It may be that we need another similar hack to make it work on your system.

[lattner]

This is related to bug 274.

[edwintorok]

The test works fine for me on darwin/x86. Are you on linux?

Yes, linux x86-64.

IF so, it would
be interesting to find out why the hack in
lib/ExececutionEngine/JIT/Intercept.cpp isn't working (search for 'stat' in
that file). It may be that we need another similar hack to make it work on
your system.

Problem is that stat from libc_nonshared.a is a local symbol, and despite of using -Wl,--export-dynamic, it stays a local symbol, hence dlsym() can't find it.

See for examples below.

I have a patch in mind, attaching.

This doesn't work:

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <sys/stat.h>

int main( void )
{
stat(NULL,NULL);
void* d = dlopen(0,RTLD_GLOBAL);
printf("%d\n",dlsym(d,"_stat"));
return 0;
}
$ gcc -Wl,-E p.c -ldl
$ ./a.out
0
$ nm a.out | grep stat
0000000000400910 t __stat
U __xstat@@GLIBC_2.2.5
0000000000400910 t stat

This does work:

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
#include <sys/stat.h>

int _stat(const char * path, struct stat * buf)
{
return stat(path, buf);
}

int main( void )
{
stat(NULL,NULL);
void* d = dlopen(0,RTLD_GLOBAL);
printf("%d\n",dlsym(d,"_stat"));
return 0;
}

$gcc -Wl,-E p.c -ldl
$ ./a.out
4196408
$ nm a.out|grep stat
0000000000400950 t __stat
U __xstat@@GLIBC_2.2.5
0000000000400838 T _stat
0000000000400950 t stat

[edwintorok]

use AddSymbol to explicitly add the address of stat symbols
Don't rely on the linker to make stat symbols exported and accessible via dlsym(),
just add the symbols explicitly.

[lattner]

Patch looks great to me, applied:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071231/056752.html

Thanks!

-Chris