llvm dev - Nov 2012 - [LLVMdev] MC and admisible function names

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?

Hi Ó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't being found.

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Óscar Fuentes
Sent: Friday, November 30, 2012 8:59 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] MC and admisible function names

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?

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hello Andy,

"Kaylor, Andrew" <andrew.kaylor at intel.com> writes:
> 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).
Yep, apparently those names with characters 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 the function isn't being
> found.
RuntimeDyldImpl::loadObject loads the mangled names, but
RuntimeDyldImpl::getSymbolLoadAddress does not try to "normalize" the
symbol name to conform to the rules of the object format, so it looks
for the user-provided name, which fails.

I guess that the solution is to transparently "normalize" the symbol
name being searched before the lookup into the object's symbol table
(but not when using JITMemoryManager::getPointerToNamedFunction, which
works on the user's private namespace and is independent of the object.)