[llvm-dev] Orc/MCJIT: Relocations vs pointers to functions
Lang Hames via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 3 10:13:51 PDT 2016
IIRC MCJIT uses SectionMemoryManager by default.
That's right, and it will use that to provide whatever functionality
(memory management or symbol resolution) the user doesn't explicitly
Can I just provide my implementation of RuntimeDyld::SymbolResolver or do I
> have to inherit from whole SectionMemoryManager?
You can just subclass RuntimeDyld::SymbolResolver and call
setSymbolResolver, and let MCJIT take care of the memory management.
If/when you switch over to ORC you'll need to provide both a symbol
resolver and memory manager with each call to addModuleSet, but for the
memory manager that's usually just a case of calling
On Thu, Jun 2, 2016 at 7:18 AM, Paweł Bylica <chfast at gmail.com> wrote:
> Quick question, using MCJIT/LLVM 3.8:
> EngineBuilder has 3 methods:
> &setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
> setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
> setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
> IIRC MCJIT uses SectionMemoryManager by default. Can I just provide my
> implementation of RuntimeDyld::SymbolResolver or do I have to inherit
> from whole SectionMemoryManager?
> On Thu, May 12, 2016 at 9:06 PM Paweł Bylica <chfast at gmail.com> wrote:
>> Currently using MCJIT. But migration to ORC is on my TODO list.
>> - Paweł
>> On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote:
>>> Hi Pawel,
>>> Option (1) and (3) are very similar, but using custom resolution (option
>>> 3) guarantees that JIT'd code can't accidentally end up depending on
>>> functions in your JIT that you didn't mean to expose. Having a smaller
>>> symbol lookup space may improve performance too.
>>> Option (2) would work, but there's no advantage vs option (3).
>>> So I recommend option 3. :)
>>> If you're using MCJIT you can override the findSymbol method on the
>>> MemoryManager. If you're using ORC you can pass a custom resolver to
>>> On Wed, May 11, 2016 at 6:47 AM, Paweł Bylica <chfast at gmail.com> wrote:
>>>> Hi LLVM, Lang.
>>>> I'm looking for a advice here. And I truly understand very little what
>>>> the relocations are and how they work.
>>>> The problem I want to solve is the case where a jitted code has to call
>>>> back the host application to query additional data. I can think of 3
>>>> possible solutions:
>>>> 1. Use built-in relocation resolver (in default memory manager?)
>>>> and allow the JIT to find the callback function by name. The host
>>>> application needs to contain symbols that the JIT will search for. You can
>>>> have only single implementation of them. The JIT will need to search in the
>>>> set of all symbols in the executable.
>>>> 2. Pass addresses of callback functions as pointers to functions to
>>>> a jitted function. The generated code should use pointer to functions
>>>> instead of predefined function names in calls.
>>>> 3. Create you own Memory Manager that will provide addresses to
>>>> callback functions. Because the set of callback functions is known upfront
>>>> and quite small that seems to be better than 1.
>>>> Can you help me to evaluate the solutions?
>>>> - Paweł
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev