[LLVMdev] MCJIT handling of linkonce_odr
Axel Naumann
Axel.Naumann at cern.ch
Mon Jan 12 02:45:45 PST 2015
Hi,
I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I
only ran into this issue:
$ cat linkonceodr.cxx
extern "C" int printf(const char*,...);
template <class T> struct StaticStuff {
static T s_data;
};
template <class T> T StaticStuff<T>::s_data = 42;
int compareAddr(int* mcjit);
#ifdef BUILD_SHARED
int compareAddr(int* mcjit) {
if (mcjit != &StaticStuff<int>::s_data) {
printf("Wrong address, %ld in shared lib, %ld in mcjit!\n",
(long)&StaticStuff<int>::s_data, (long)mcjit);
return 1;
}
return 0;
}
#else
int main(int, char**) {
return compareAddr(&StaticStuff<int>::s_data);
}
#endif
$ clang++ -fPIC -shared -DBUILD_SHARED -o liblinkonceodr.so linkonceodr.cxx
$ clang++ -emit-llvm -c linkonceodr.cxx -o - |
LD_PRELOAD=./liblinkonceodr.so lli -
Wrong address, 140449908087496 in shared lib, 140449908076544 in mcjit!
I.e. while compareAddr is resolved from the dylib, this:
@_ZN11StaticStuffIiE6s_dataE = linkonce_odr global i32 42, align 4
is not: it is re-emitted by the MCJIT. When building a binary and
linking against that dylib, _ZN11StaticStuffIiE6s is correctly picked up
from the dylib. I would expect MCJIT to behave the same.
I'll try to fix that myself, but I'd appreciate a hint where to do that.
Should I collect linkonce_odr-s and "replace" their emitted code as part
of llvm::RuntimeDyldImpl::resolveRelocations()? Or is this just a
missing case somewhere?
That's e.g. with
$ lli --version
LLVM (http://llvm.org/):
LLVM version 3.6.0svn
Optimized build.
Built Jan 12 2015 (10:52:59).
Default target: x86_64-unknown-linux-gnu
Host CPU: corei7-avx
Cheers, Axel.
More information about the llvm-dev
mailing list