[llvm-dev] Linking existing functions from JITed code

[Andy Somogyi via llvm-dev]

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>