Hi,

This caused llvm builds to fail for me (using clang-14, debug, debian unstable, lld as linker):

So far the tests in pointer-subtraction.c are mirrored in pointer-subtraction.cpp - worth continuing to do?

It's not really the fault of this change, but the gdb support isn't really restricted to mcjit. registerJITEventListener() works with RTDyld based Orc too.

Gentle ping.

Darnit. Sorry for that. Good catch. Can you commit, or should I?

This looks like a sensible improvement. There's probably not many implementors of the interface, so the renaming shouldn't cause much pain.

Previous approach was a brick shy of a load, which I realized after
sleeping on it. We'd just end up with undefined symbol errors for the
listeners that *are* built in (because the part of the class
implementation ptentially is in a different lib). Hence just define
if necessary.

In D44892#1168466, @irogers wrote:

Given that the listener has no dependencies, it might be sensible to
enable it by default when running on linux.

Fwiw, I agree with this except I would add an option to lli so that generating the perf jitdump data was optional - otherwise you could end up filling a disk, .. unexpectedly.

@vchuravy Yea, that was an unnecessary, and as you notice wrong, dependency. I confirmed that just removing it is sufficient. Does that resolve your blocker?

Fix build without perf enabled, fix rebasing issues.

Address reames' comments and rebase onto newer code. As
https://reviews.llvm.org/D44890 has landed, add the corresponding
C-API function as well.

This patch doesn't affect any of my use-cases, but it's possible that some clients are relying on the fact that memory will still be writable at this point.

Rebase after temporary revert of r333147.

FWIW, I don't think this is really obvious / trivial enough to land w/o review by someone familiar w/ Orc and the users.

In D44889#1110390, @lhames wrote:

Looks good to me. Do you have commit access? If not I can commit on your behalf.

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

Ping? Any suggestions for other reviewers?

Ping? This is a simple enough addition that seems to have been envisioned when designing the Orc C stack (given that the underlying stack isn't used anywhere else, and has findSymbolIn()).

Ideally we would have a test for this code but given that it involves host CPU and features this seems quite tricky and not worth the benefit.

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.

Ping? This is a trivial change and makes it much easier to use Orc via the C API, as otherwise suboptimal code is generated. If anybody has suggestions for further reviewers I'd also be happy.