[llvm-dev] Orc/MCJIT: Relocations vs pointers to functions

[Lang Hames via llvm-dev]

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/20160512/20c91453/attachment.html>