llvm dev - Aug 2015 - Linking existing functions from JITed code

Hi

I’ve previously used the ExecutionEngine::addGlobalMapping to make existing
functions available to my JITed code.

I’m currently using ORC, as MCJIT does not appear to be maintained any
longer (the kaleidoscope examples have not worked for some time with
MCJIT).

I’m using just the basic ORC CompileLayer directly.

So, I’ve essentially copied the ExecutionEngine::addGlobalMapping related
function to my JIT context, and I create a lambda resolver as such:

JITContext::addModule(…) {

auto Resolver = createLambdaResolver(
[&](const std::string &name) {

// look up first in JIT'ed code
if (auto sym = findMangledSymbol(name)) {
return RuntimeDyld::SymbolInfo(sym.getAddress(),
sym.getFlags());
return RuntimeDyld::SymbolInfo(nullptr);
}

// look up in added globals
if (auto addr = getPointerToGlobalMapping(name)) {
return RuntimeDyld::SymbolInfo(addr, JITSymbolFlags::Exported);
}

// finally try to look up existing process symbols, note
// this works for symbols loaded in shared libraries, but
// does NOT seem to find symbols declared in the executable.
if (auto Addr RTDyldMemoryManager::getSymbolAddressInProcess(name)) {
return RuntimeDyld::SymbolInfo(Addr, JITSymbolFlags::Exported);
}
},
[](const std::string &S) { return nullptr; }
);
}

Here the getPointerToGlobalMapping function looks in a uint64 StringMap
into which values are added via the addGlobalMapping functions.


This approach seems to be working, but my question is do you suppose there
any are issues with such an approach?

The troubling thing is why doesn’t  RTDyldMemoryManager::
getSymbolAddressInProcess(name)) return an address for a symbol that is
defined in either a static library, or in the executable itself.

If this approach is correct, in adding the global values to the context,
and looking them up the lambda resolver, in addition to looking up external
symbols, and considering that the ORC kaleidoscope examples do in fact
allow external function calls (which are broken currently), should they be
fixed with this approach?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/19100533/attachment.html>

+"Lang Hames, Linker of Linkers"

(Lang developed the ORC JIT you seem to be using & can provide more context
than I have)

On Thu, Aug 13, 2015 at 12:43 PM, Andy Somogyi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi
>
> I’ve previously used the ExecutionEngine::addGlobalMapping to make
> existing functions available to my JITed code.
>
> I’m currently using ORC, as MCJIT does not appear to be maintained any
> longer (the kaleidoscope examples have not worked for some time with
> MCJIT).
>
> I’m using just the basic ORC CompileLayer directly.
>
> So, I’ve essentially copied the ExecutionEngine::addGlobalMapping related
> function to my JIT context, and I create a lambda resolver as such:
>
> JITContext::addModule(…) {
>
> auto Resolver = createLambdaResolver(
> [&](const std::string &name) {
>
> // look up first in JIT'ed code
> if (auto sym = findMangledSymbol(name)) {
> return RuntimeDyld::SymbolInfo(sym.getAddress(),
> sym.getFlags());
> return RuntimeDyld::SymbolInfo(nullptr);
> }
>
> // look up in added globals
> if (auto addr = getPointerToGlobalMapping(name)) {
> return RuntimeDyld::SymbolInfo(addr, JITSymbolFlags::Exported);
> }
>
> // finally try to look up existing process symbols, note
> // this works for symbols loaded in shared libraries, but
> // does NOT seem to find symbols declared in the executable.
> if (auto Addr > RTDyldMemoryManager::getSymbolAddressInProcess(name)) {
> return RuntimeDyld::SymbolInfo(Addr, JITSymbolFlags::Exported);
> }
> },
> [](const std::string &S) { return nullptr; }
> );
> }
>
> Here the getPointerToGlobalMapping function looks in a uint64 StringMap
> into which values are added via the addGlobalMapping functions.
>
>
> This approach seems to be working, but my question is do you suppose there
> any are issues with such an approach?
>
> The troubling thing is why doesn’t  RTDyldMemoryManager::
> getSymbolAddressInProcess(name)) return an address for a symbol that is
> defined in either a static library, or in the executable itself.
>
> If this approach is correct, in adding the global values to the context,
> and looking them up the lambda resolver, in addition to looking up external
> symbols, and considering that the ORC kaleidoscope examples do in fact
> allow external function calls (which are broken currently), should they be
> fixed with this approach?
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/27d046ca/attachment.html>

Hi Andy,

I haven't tested this on Linux, but on MacOS the
RuntimeDyldMemorManager::getSymbolAddressInProcess method should find
symbol addresses in the host program, including symbols from static
archives linked into the program. However, one gotcha is that the symbol
has to be reachable from main, otherwise the linker may strip it from the
final executable.

Do you have a test-case that I could try to reproduce the issue with?

Alternatively, if you run the code under a debugger, do you see symbols
that the JIT failed to find? If the symbols are visible in the debugger but
invisible to the JIT that sounds like a bug in the JIT. If the symbols are
invisible in both that would suggest that the linker is stripping them out.

- Lang.


On Thu, Aug 13, 2015 at 1:12 PM, David Blaikie <dblaikie at gmail.com>
wrote:
> +"Lang Hames, Linker of Linkers"
>
> (Lang developed the ORC JIT you seem to be using & can provide more
> context than I have)
>
> On Thu, Aug 13, 2015 at 12:43 PM, Andy Somogyi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi
>>
>> I’ve previously used the ExecutionEngine::addGlobalMapping to make
>> existing functions available to my JITed code.
>>
>> I’m currently using ORC, as MCJIT does not appear to be maintained any
>> longer (the kaleidoscope examples have not worked for some time with
>> MCJIT).
>>
>> I’m using just the basic ORC CompileLayer directly.
>>
>> So, I’ve essentially copied the ExecutionEngine::addGlobalMapping
related
>> function to my JIT context, and I create a lambda resolver as such:
>>
>> JITContext::addModule(…) {
>>
>> auto Resolver = createLambdaResolver(
>> [&](const std::string &name) {
>>
>> // look up first in JIT'ed code
>> if (auto sym = findMangledSymbol(name)) {
>> return RuntimeDyld::SymbolInfo(sym.getAddress(),
>> sym.getFlags());
>> return RuntimeDyld::SymbolInfo(nullptr);
>> }
>>
>> // look up in added globals
>> if (auto addr = getPointerToGlobalMapping(name)) {
>> return RuntimeDyld::SymbolInfo(addr, JITSymbolFlags::Exported);
>> }
>>
>> // finally try to look up existing process symbols, note
>> // this works for symbols loaded in shared libraries, but
>> // does NOT seem to find symbols declared in the executable.
>> if (auto Addr >>
RTDyldMemoryManager::getSymbolAddressInProcess(name)) {
>> return RuntimeDyld::SymbolInfo(Addr, JITSymbolFlags::Exported);
>> }
>> },
>> [](const std::string &S) { return nullptr; }
>> );
>> }
>>
>> Here the getPointerToGlobalMapping function looks in a uint64 StringMap
>> into which values are added via the addGlobalMapping functions.
>>
>>
>> This approach seems to be working, but my question is do you suppose
>> there any are issues with such an approach?
>>
>> The troubling thing is why doesn’t  RTDyldMemoryManager::
>> getSymbolAddressInProcess(name)) return an address for a symbol that is
>> defined in either a static library, or in the executable itself.
>>
>> If this approach is correct, in adding the global values to the
context,
>> and looking them up the lambda resolver, in addition to looking up
external
>> symbols, and considering that the ORC kaleidoscope examples do in fact
>> allow external function calls (which are broken currently), should they
be
>> fixed with this approach?
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/d4d6427f/attachment.html>

On Thu, Aug 13, 2015 at 12:44 PM Andy Somogyi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi
>
> I’ve previously used the ExecutionEngine::addGlobalMapping to make
> existing functions available to my JITed code.
>
> I’m currently using ORC, as MCJIT does not appear to be maintained any
> longer (the kaleidoscope examples have not worked for some time with
> MCJIT).
>
>
Which MCJIT tutorials are you building here? The ones linked from the
website should work just fine - and all of the jit uses MCJIT underneath
the covers in some way or another.

Code link/pointer?

-eric

> I’m using just the basic ORC CompileLayer directly.
>
> So, I’ve essentially copied the ExecutionEngine::addGlobalMapping related
> function to my JIT context, and I create a lambda resolver as such:
>
> JITContext::addModule(…) {
>
> auto Resolver = createLambdaResolver(
> [&](const std::string &name) {
>
> // look up first in JIT'ed code
> if (auto sym = findMangledSymbol(name)) {
> return RuntimeDyld::SymbolInfo(sym.getAddress(),
> sym.getFlags());
> return RuntimeDyld::SymbolInfo(nullptr);
> }
>
> // look up in added globals
> if (auto addr = getPointerToGlobalMapping(name)) {
> return RuntimeDyld::SymbolInfo(addr, JITSymbolFlags::Exported);
> }
>
> // finally try to look up existing process symbols, note
> // this works for symbols loaded in shared libraries, but
> // does NOT seem to find symbols declared in the executable.
> if (auto Addr > RTDyldMemoryManager::getSymbolAddressInProcess(name)) {
> return RuntimeDyld::SymbolInfo(Addr, JITSymbolFlags::Exported);
> }
> },
> [](const std::string &S) { return nullptr; }
> );
> }
>
> Here the getPointerToGlobalMapping function looks in a uint64 StringMap
> into which values are added via the addGlobalMapping functions.
>
>
> This approach seems to be working, but my question is do you suppose there
> any are issues with such an approach?
>
> The troubling thing is why doesn’t  RTDyldMemoryManager::
> getSymbolAddressInProcess(name)) return an address for a symbol that is
> defined in either a static library, or in the executable itself.
>
> If this approach is correct, in adding the global values to the context,
> and looking them up the lambda resolver, in addition to looking up external
> symbols, and considering that the ORC kaleidoscope examples do in fact
> allow external function calls (which are broken currently), should they be
> fixed with this approach?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150814/aa13e705/attachment.html>

> On Aug 13, 2015, at 8:22 PM, Eric Christopher <echristo at gmail.com>
wrote:
> On Thu, Aug 13, 2015 at 12:44 PM Andy Somogyi via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi
> 
> I’ve previously used the ExecutionEngine::addGlobalMapping to make existing
functions available to my JITed code.
> 
> I’m currently using ORC, as MCJIT does not appear to be maintained any
longer (the kaleidoscope examples have not worked for some time with MCJIT).
> 
> 
> Which MCJIT tutorials are you building here? The ones linked from the
website should work just fine - and all of the jit uses MCJIT underneath the
covers in some way or another.
> 
> Code link/pointer?
> 
> -eric
Hi Eric, 

The standard Kaleidoscope examples do compile, like this one:

https://github.com/llvm-mirror/llvm/blob/master/examples/Kaleidoscope/Chapter7/toy.cpp
<https://github.com/llvm-mirror/llvm/blob/master/examples/Kaleidoscope/Chapter7/toy.cpp>

However, only the first JITed function works. The problem is MCJIT does not
support adding new functions like the previous standard JIT did. The only way
for MCJIT to support adding functions is to create new MCJIT engine instances,
and set up the symbol resolver to look in previous instances for existing
symbols.

This kind of code used to be working in 

https://github.com/llvm-mirror/llvm/tree/master/examples/Kaleidoscope/MCJIT
<https://github.com/llvm-mirror/llvm/tree/master/examples/Kaleidoscope/MCJIT>

However, the last time I checked, a month or so ago, none of the examples in the
Kaleidoscope/MCJIT would compile.

Also, Lang, I'm not sure if the ORC MCJITReplacement supports the
ExecutionEngine::addGlobalMapping methods. It looks like the lambda resolver
that the MCJITReplacement uses ignores all the values in the global address map
when it resolves symbols.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150814/2538a4e9/attachment.html>