This is an archive of the discontinued LLVM Phabricator instance.

Allow to integrate OrcJIT with JitEventListeners
ClosedPublic

Authored by anarazel on Mar 25 2018, 10:02 PM.

Details

Summary

See #31521

Contained-Commits:

[ORC] Extend object layer callbacks so JITEventListener can be supported.

Currently the RTDyldObjectLinkingLayer makes it hard to support
JITEventListeners. Which in turn means debugging and profiling JIT
generated code hard.

Supporting JITEventListeners at minimum requries a freed
callback (added).

As listeners expect the ObjectFile to be passed as well, an adaptor
between RTDyldObjectLinkingLayer and JITEventListeners would currently
need to also maintain ObjectFiles for all loaded modules. To make that
less awkward extend the callbacks to pass the ObjectFile to both
Finalized and Freed callbacks. That requires extending the lifetime
of the object file when callbacks are present.

[ORC] Add ability [un]register JITEventListener on C Orc stack.

[ORC][C-API] Expose LLVMOrc{Unr,R}egisterJITEventListener().

[C-API] Add functions to create GDB, Intel, Oprofile event listeners.

Intel and Oprofile were done blindly, I don't have the environment to
build them.

Diff Detail

Event Timeline

anarazel created this revision.Mar 25 2018, 10:02 PM
anarazel retitled this revision from Allow to integrate OrcJIT with JitEventListeners See #31521 Contained-Commits: [ORC] Extend object layer callbacks so JITEventListener can be supported. to Allow to integrate OrcJIT with JitEventListeners.Mar 25 2018, 10:03 PM
anarazel edited the summary of this revision. (Show Details)
anarazel added a reviewer: lhames.

Ping? I'm using this functionality in postgres's new JIT support. It'd be cool if it were merged so we can make sure the released version of Postgres is going to use the right API, even if LLVM has to be patched for it to be available in older releases.

We're using it both for debugging and profiling support (see https://reviews.llvm.org/D44892).

Ping? @lhames unfortunately you're probably the only one to review this?

include/llvm-c/ExecutionEngine.h
187

Create is wrong for at least GDB which essentially is a singleton, but I don' tthink it's helpful to deviate from the underlying name.

include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h
167

This isn't pretty, but I don't quite see a good alternative.

lib/ExecutionEngine/Orc/OrcCBindingsStack.h
428

This ain't algorithmically efficient, but I can't see enough listeners being registered for that to matter.

gipri added a subscriber: gipri.May 14 2018, 1:07 AM
lhames accepted this revision.May 23 2018, 4:18 PM

Looks good to me! (Sorry for the belated reply!)

This revision is now accepted and ready to land.May 23 2018, 4:18 PM
This revision was automatically updated to reflect the committed changes.