Apolgoies, won't have any bandwidth for this for a few days (and haven't looked at EPCDebugObjectRegistrar yet). If it a) compiles on macOS/ARM64, and b) registers a code block with LLDB in a cursory test (I forget whether there is CI test coverage), it's probably fine.

Just saw that this is still sitting unmerged – I'm not sure I have much useful to add (and no commit access either way).

I might have enabled DebugObjectManagerPlugin only when targeting ELF and
GDBJITDebugInfoRegistrationPlugin only when targeting MachO to avoid the performance overhead, but I suppose the cost should be very small.

I'm also not sure whether there is any advantage to synthesising the JITDylib entries only for Create to the immediately look them up; or rather, the AllocAction – I think llvm_orc_registerJITLoaderGDBWrapper is only used by the EPCDebugObjectRegistrar.

Does this turn off the ability to do JIT debugging on macho? (I'm not sure this ever worked but in a more theoritical sense)

I'm also not sure whether there is any advantage to synthesising the JITDylib entries only for Create to the immediately look them up; or rather, the AllocAction – I think llvm_orc_registerJITLoaderGDBWrapper is only used by the EPCDebugObjectRegistrar.

There isn't any immediate benefit, but I figure the cost is pretty low to route it through Create, and maybe in the future upstream LLVM will do something fancy in Create that can't be applied to a new call (e.g. give back the correct plugin).

Does this turn off the ability to do JIT debugging on macho? (I'm not sure this ever worked but in a more theoritical sense)

No, we still add the MachO plugin when we're emitting to MachO format.