This is an archive of the discontinued LLVM Phabricator instance.

[MCJIT] Add a FindGlobalVariableNamed utility
ClosedPublic

Authored by loladiro on Jun 12 2015, 2:37 PM.

Details

Summary

This adds FindGlobalVariableNamed to ExecutionEngine (plus implementation in MCJIT), which is an analog of FindFunctionNamed for GlobalVariables.

Diff Detail

Repository
rL LLVM

Event Timeline

loladiro updated this revision to Diff 27602.Jun 12 2015, 2:37 PM
loladiro retitled this revision from to [MCJIT] Add two useful utility functions.
loladiro updated this object.
loladiro edited the test plan for this revision. (Show Details)
loladiro added a reviewer: lhames.
loladiro set the repository for this revision to rL LLVM.
loladiro added a subscriber: Unknown Object (MLST).
lhames edited edge metadata.Jun 17 2015, 11:27 AM

Hi Keno,

The FindGlobalVariableNamed part looks good. Could you add a unit test?

Normally the loaded object info should be captured by adding an EventListener. Would it be possible for you to use that? (Or is that mechanism broken in some way?). As much as reasonably possible I want to keep the MCJIT interface in check.

Sure, I'll add a test. The use case for the LoadObjectFile method was to hand off a single object file that I generated and be able to look at it. Adding an event listener didn't really work because I don't know which of the hundreds of events corresponded to the object file I want. I suppose I could after the fact query the execution engine for the address of one of the symbols in the module and look through a map of addresses to object files I create in an event listener - but that just seemed like too much effort for information which is actually readily available, but just gets discarded.

When you call addObjectFile, MCJIT will call NotifyObjectEmitted immediately on each registered event listener, passing a reference to the original ObjectFile, and to the LoadedObjectInfo. If you specifically want to inspect the object file currently being loaded you could raise a flag on your event listener:

MyEventListener.NextObjectIsSpecial = true;
EE->addObjectFile(...);

I'm not a fan of callbacks in general, and I agree that this is a bit ugly. However, I prefer callbacks for handling loaded objects in MCJIT because they encourage you to treat JIT'd objects and precompiled ones uniformly, which is usually what you want.

If you feel strongly about this I don't mind the method being added, as long as it's not exposed via the C API.

Shameless plug: In Orc you could add trivial custom layer for this. ;)

Wouldn't that fail if the loaded object contained a dependency on a symbol in another loaded, but not-yet-codegened module?

No - Loaded doesn't imply finalized, and you don't have to resolve dependencies until finalization.

Right, ok. That does seem like a viable strategy then. I'll add the unit test and drop the LoadObjectFile functions.

loladiro updated this revision to Diff 27950.Jun 18 2015, 12:25 PM
loladiro retitled this revision from [MCJIT] Add two useful utility functions to [MCJIT] Add a FindGlobalVariableNamed utility.
loladiro updated this object.
loladiro edited edge metadata.

Updated as discussed.

lhames accepted this revision.Jun 19 2015, 12:58 PM
lhames edited edge metadata.

Thanks Keno. Looks good to me!

This revision is now accepted and ready to land.Jun 19 2015, 12:58 PM
This revision was automatically updated to reflect the committed changes.