This adds FindGlobalVariableNamed to ExecutionEngine (plus implementation in MCJIT), which is an analog of FindFunctionNamed for GlobalVariables.
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;
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. ;)