Orc/MCJIT: Relocations vs pointers to functions

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ł

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. :slight_smile:

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.

Thanks!

Currently using MCJIT. But migration to ORC is on my TODO list.

  • Paweł

Quick question, using MCJIT/LLVM 3.8:
EngineBuilder has 3 methods:

EngineBuilder &setMCJITMemoryManager(std::unique_ptr mcjmm);

EngineBuilder&
setMemoryManager(std::unique_ptr MM);

EngineBuilder&
setSymbolResolver(std::unique_ptrRuntimeDyld::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?

Hi Pawel,

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 override.

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 llvm::make_unique().

  • Lang.