[LLVMdev] MCJIT finalizeObject output to use in external process

Dave Pitsbawn dpitsbawn at gmail.com
Wed Mar 25 16:59:40 PDT 2015


Aha. Thanks.

Seems like I need to call mapSectionAddress with the target address. But
how I copy the code? What function would I call?

On Wed, Mar 25, 2015 at 4:32 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

>  Yes, that is one of the intended use models for MCJIT.
>
>
>
> If you look at the source for ‘lli’ you’ll find an option called
> “remote-mcjit” which does exactly this (for testing purposes).
>
>
>
> The key function (which in the lli case is called from lli’s
> RemoteMemoryManager::notifyObjectLoaded method) is
> ExecutionEngine::mapSectionAddress.  This function tells MCJIT to reapply
> relocations to the loaded object as if it were loaded at a different
> address in memory than it actually is.  The client is responsible for the
> particulars of allocating memory in the remote process, determining the
> address of the memory in the remote process’ address space and (after
> calling mapSectionAddress) copying the JIT’d object to the remote process
> memory and setting the memory attributes as needed for execution.
>
>
>
> -Andy
>
>
>
>
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On
> Behalf Of *Dave Pitsbawn
> *Sent:* Wednesday, March 25, 2015 4:07 PM
> *To:* LLVM Developers Mailing List
> *Subject:* [LLVMdev] MCJIT finalizeObject output to use in external
> process
>
>
>
> A need has arisen to generate code using MCJIT but not in the target
> process instead in a different process (and possibly even different machine
> though not in the scope).
>
>
>
> Reading through the tutorials and MCJIT design document, it seems like
> this is possible or was kept in mind during design of MCJIT.
>
>
>
> How do I achieve this? Are there examples?
>
>
>
> Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150325/9f1add29/attachment.html>


More information about the llvm-dev mailing list