[llvm-dev] Linking existing functions from JITed code

[David Blaikie via llvm-dev]

+"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>