[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