[llvm-dev] Orc/MCJIT: Relocations vs pointers to functions
Paweł Bylica via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 2 07:18:41 PDT 2016
Quick question, using MCJIT/LLVM 3.8:
EngineBuilder has 3 methods:
EngineBuilder &setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager>
mcjmm);
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
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:
> Thanks!
>
> 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
>> addModuleSet.
>>
>> Cheers,
>> Lang.
>>
>>
>> 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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/72e4d4a2/attachment.html>
More information about the llvm-dev
mailing list