search for: getsymbolloadaddress

While using MCJIT, when I define a function with name Fn_.._lib_rc-variant.lp0_17_0x706970 ExecutionEngine::getPointerToFunction fails to locate it (returns 0). There is no problem if the function is named Fn_0x706970. There is no problem with those names using the traditional JIT. Is there any special limitation on function names for MC/MCJIT?

...s outside the acceptable range of the object file format in use (ELF, in my case) are mangled, so this name: Fn_.._lib_rc-variant.lp0_17_0x706970 becomes this: Fn_.._lib_rc_2D_variant.lp0_17_0x706970 > When you call getPointerToFunction in MCJIT, it will ultimately call > RuntimeDyldImpl::getSymbolLoadAddress to look the name up in a table > of known function names. That table gets built from the emitted object > image during the RuntimeDyldImpl::loadObject call. If you set a > breakpoint in that function you can see all the symbol names that get > processed and it will probably tell you why...

Hi all, are there any plans to correct/implement the "getPointerToGlobal()" method for accessing global variables that are emitted by MCJIT? (see for details the unit test of MCJIT) Best Regards Armin

As far as I know, no one is working to fix the test case in question. Patches welcome :) Cheers, Dan On 2012-11-13, at 1:29 AM, "Armin Steinhoff" <armin at steinhoff.de> wrote: > > Hi all, > > are there any plans to correct/implement the "getPointerToGlobal()" method for accessing global variables that are emitted by MCJIT? > (see for details the

...scar, I'm not aware of any intentional function name limitations with MCJIT. It's entirely possible that something somewhere is rejecting the name for one reason or another (intentionally or otherwise). When you call getPointerToFunction in MCJIT, it will ultimately call RuntimeDyldImpl::getSymbolLoadAddress to look the name up in a table of known function names. That table gets built from the emitted object image during the RuntimeDyldImpl::loadObject call. If you set a breakpoint in that function you can see all the symbol names that get processed and it will probably tell you why the function isn&...

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74