[LLVMdev] MCJit interface question

[Lang Hames]

Hi Joseph,

There are several reasons that a client might want to access the object
before it's loaded, so a general API like #2 seems like the way to go.

To support this in MCJIT you can add this to the event listener API. Orc
clients can already do this by adding a custom object-file layer.

- Lang.



On Fri, May 29, 2015 at 9:05 AM, Joseph Tremoulet <jotrem at microsoft.com>
wrote:

>  Hi,
>
>
>
> I think I need to make a small change to the MCJit interface, and would
> like some feedback on what the most appropriate option would be.
>
>
>
> I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates
> one module for each MSIL method, containing the main function and zero or
> more EH handler functions extracted from the MSIL method).  The CoreCLR
> requires the jit to notify it of the size of the unwind info descriptors
> for each function in the module *before* reserving the memory it will be
> loaded into.  So we need a call (or calls) from the Jit/loader into the
> MemoryManager that runs at-or-before reserveAllocationSpace, is
> conceptually similar to registerEHFrames in that it's reserving EH frames,
> but that additionally needs to separate out the per-function information.
>
>
>
> A few options come to mind:
>
> 1.       Add a needsToReserveEHFrames callback on MemoryManager (to
> parallel needsToReserveAllocationSpace), and a reserveEHFrames callback
> (parallel to registerEHFrames) that the loader would use to notify the
> memory manager if needsToReserveEHFrames() is true.  This seems at a
> high-level the most straightforward fit for the LLILC requirement, but I
> don't know if for other targets it would even be possible to move the
> identification of EH frames (which depends on the 'LocalSections' computed
> in loadObjectImpl) to before calling reserveAllocationSpace.  I also don't
> know if that would be an undesirable "tight coupling" of RuntimeDyld with
> CoreCLR's particular interface. (and note that this is really two options,
> in that the code to separate out the per-function EH frame contribution
> could go in either the client memory manager or in the loader.)
>
> 2.       Add a notification similar to NotifyObjectEmitted, but which
> runs just *before* the call to Dyld.loadObject.  Something like
> NotifyObjectPreLoaded.  The LLILC-specific MemoryManager could use this
> hook to scan the object::ObjectFile and pass whatever it needs to the
> CoreCLR.  This seems like a decent option to me, but I don't know if it
> would be considered a bad loss of encapsulation to passs out the
> object::ObjectFile in the state where it's been 'created' but not yet
> 'loaded'.
>
> 3.       Similar to #2, the existing reserveAllocationSpace callback on
> MemoryManager could simply take an additional parameter which is the
> object::ObjectFile.  This would be a more minimal change than #2 in terms
> of how much surface area it adds to the MCJit interface, but also a more
> invasive change in that all MemoryManager implementations would need to be
> updated with the reserveAllocationSpace signature change (though they could
> just ignore the new parameter).
>
> 4.       We could avoid needing to crack the object file for this
> information altogether; MCJit could add a hook where a client could insert
> passes into the PassManager used in emitObject; LLILC could attach a pass
> that would consult the MachineModuleInfo, where this information could be
> stored (it's similar to what's stored in the WinEHFuncInfos hanging off the
> MMI today).  But adding hooks for client passes might be opening a can of
> worms…
>
>
>
> My inclination would be #2 or #3, but I would love some feedback on which
> of the tradeoffs seem most agreeable (and/or what options I've overlooked).
>
>
>
> Thanks
>
> -Joseph
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150529/cf39a321/attachment.html>