lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode

Hi,
   LLVM/Clang version: 3.2svn (r156975). I have a bitcode file that I'm trying to load/execute using lli as below but it reports an error about unresolved symbol:

LLVM ERROR: Program used external function '_ZNKSt3__16locale9use_facetERNS0_2idE' which could not be resolved!
lli: /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/llvm/lib/Support/ThreadLocal.cpp:54: virtual llvm::sys::ThreadLocalImpl::~ThreadLocalImpl(): Assertion `errorcode ==

   I've tried loading the following libs when running lli:

lli \
-load=libQtCore.so.4 \
-load=libpthread.so.0 \
-load=libm.so.6 \
-load=libgcc_s.so.1 \
-load=libc.so.6 \
-load=libz.so.1 \
-load=libgthread-2.0.so.0 \
-load=libglib-2.0.so.0 \
-load=librt.so.1 \
-load=libpcre.so.3 \
-load=libdl.so.2 \
-load=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 \
-use-mcjit -entry-function="ISimEngine_GetVersion" /local/mnt/workspace/ashoknn/crd/neo/llvm/IIF/HLND.bc/libengine.bc

Anything missing above? I tried using libstdc++.so.6 as well as its full path as above, same error.

Thanks,
Ashok

Resending, any pointers? I demangled the symbol and it turns out to be:
std::__1::locale::use_facet(std::__1::locale::id&) const

tia,
ashok

Ashok Nalkund wrote:

Resending, any pointers? I demangled the symbol and it turns out to be:
std::__1::locale::use_facet(std::__1::locale::id&) const

My guess is that you've got a .bc file produced on a mac using libc++ (hence the ::_1 part) and you're trying to run it on linux with libstdc++ (which doesn't use inline namespaces, the '::_1::' part). That won't work.

Nick

Thanks for the clue. I had earlier tried to use libc++ and there were some remnants of that try. I've now cleaned up and now it gets past the use_facet error.

It now complains about '__dso_handle'. I saw a bug already reported but its status is still NEW:
http://llvm.org/bugs/show_bug.cgi?id=7847

As mentioned in the bug, the problem seems to be when the interpreter is used.

There is another post on cfe-dev list:
http://clang-developers.42468.n3.nabble.com/Configuring-HAVE-DSO-HANDLE-by-CMake-td3423707.html

Any thoughts?

thanks
ashok

Resending :(. Any pointers?

tia

Resending :(. Any pointers?

Are you seeing missing __dso_handle with the interpreter or with the JIT?

Ciao, Duncan.

With MCJIT.

Ashok Nalkund wrote:

Resending :(. Any pointers?

Fundamentally the issue is that the system linker is supposed to define __dso_handle when linking, but since there is no system linker between your build of the .bc files and running lli, nobody has defined it.

It seems reasonable to me that lli should define __dso_handle if it's declared in the module.

You could module tools/lli/lli.cpp to add a global:

   char *dummy_dso_handle = 0;

and tie it to __dso_handle via.

   if (GlobalVariable *DSO = Mod->getGlobalVariable("__dso_handle"))
     if (!DSO->hasInitializer())
       EE->updateGlobalMapping(DSO, &dummy_dso_handle);

somewhere in main(), say after disabling lazy compilation. Entirely untested though; we might need to give dummy_dso_handle a real value.

Nick

Nick Lewycky wrote:

Ashok Nalkund wrote:

Resending :(. Any pointers?

Fundamentally the issue is that the system linker is supposed to define
__dso_handle when linking, but since there is no system linker between
your build of the .bc files and running lli, nobody has defined it.

It seems reasonable to me that lli should define __dso_handle if it's
declared in the module.

You could module tools/lli/lli.cpp to add a global:

    char *dummy_dso_handle = 0;

and tie it to __dso_handle via.

    if (GlobalVariable *DSO = Mod->getGlobalVariable("__dso_handle"))
      if (!DSO->hasInitializer())

Obvious error here, that should read:

       if (DSO->isDeclaration())

to test whether it's a declaration. Still untested of course. :slight_smile:

Hi Nick,

Fundamentally the issue is that the system linker is supposed to define
__dso_handle when linking, but since there is no system linker between
your build of the .bc files and running lli, nobody has defined it.

It seems reasonable to me that lli should define __dso_handle if it's
declared in the module.

You could module tools/lli/lli.cpp to add a global:

    char *dummy_dso_handle = 0;

and tie it to __dso_handle via.

    if (GlobalVariable *DSO = Mod->getGlobalVariable("__dso_handle"))
      if (!DSO->hasInitializer())
        EE->updateGlobalMapping(DSO,&dummy_dso_handle);

somewhere in main(), say after disabling lazy compilation. Entirely
untested though; we might need to give dummy_dso_handle a real value.

this is already done in JIT.cpp, search for HAVE___DSO_HANDLE. Probably
the interpreter and MCJIT just need to get the same logic.

Ciao, Duncan.

Thanks Nick/Duncan. I will to look into this and report back.