[Orc] Make usage of ResourceKeys thread-safe in DebugObjectManagerPlugin

Don't leak ResourceKeys from MaterializationResponsibility::withResourceKeyDo() in notifyEmitted().
Also make some improvemen

[Orc] Make usage of ResourceKeys thread-safe in DebugObjectManagerPlugin

Don't leak ResourceKeys from MaterializationResponsibility::withResourceKeyDo() in notifyEmitted().
Also make some improvements in the overall implementation.

Differential Revision: https://reviews.llvm.org/D98863

show more ...

[Orc] Fix tracking of pending debug objects in DebugObjectManagerPlugin

There can be multiple MaterializationResponsibilitys in-flight for a single ResourceKey. Hence, pending debug objects must be

[Orc] Fix tracking of pending debug objects in DebugObjectManagerPlugin

There can be multiple MaterializationResponsibilitys in-flight for a single ResourceKey. Hence, pending debug objects must be tracked by MaterializationResponsibility and not by ResourceKey.

Differential Revision: https://reviews.llvm.org/D98785

show more ...

[Orc] Deallocate debug objects properly when removing resources from DebugObjectManagerPlugin

[JITLink][ORC] Make the LinkGraph available to modifyPassConfig.

This makes the target triple, graph name, and full graph content available
when making decisions about how to populate the linker pas

[JITLink][ORC] Make the LinkGraph available to modifyPassConfig.

This makes the target triple, graph name, and full graph content available
when making decisions about how to populate the linker pass pipeline.

Also updates the LLJITWithObjectLinkingLayerPlugin example to show more
API use, including use of the API changes in this patch.

show more ...

[Orc] Fix race condition in DebugObjectManagerPlugin

During finalization the debug object is registered with the target. Materialization must wait for this process to finish. Otherwise we might star

[Orc] Fix race condition in DebugObjectManagerPlugin

During finalization the debug object is registered with the target. Materialization must wait for this process to finish. Otherwise we might start running code before the debugger finished processing the corresponding debug info.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D98417

show more ...

[Orc] Deallocate debug objects explicitly when destroying the DebugObjectManagerPlugin

[Orc] Always check mapped sections for ELFDebugObject are in bounds of working memory buffer

As stated in the JITLink user guide: Do not assume that the input object is well formed.
https://llvm.org

[Orc] Always check mapped sections for ELFDebugObject are in bounds of working memory buffer

As stated in the JITLink user guide: Do not assume that the input object is well formed.
https://llvm.org/docs/JITLink.html#tips-for-jitlink-backend-developers

show more ...

[Orc] Fix working memory buffer for section mapping in ELFDebugObject

[Orc] Fix MSVC error: conversion from 'initializer list' requires a narrowing

[Orc] Add JITLink debug support plugin for ELF x86-64

Add a new ObjectLinkingLayer plugin `DebugObjectManagerPlugin` and infrastructure to handle creation of `DebugObject`s as well as their registra

[Orc] Add JITLink debug support plugin for ELF x86-64

Add a new ObjectLinkingLayer plugin `DebugObjectManagerPlugin` and infrastructure to handle creation of `DebugObject`s as well as their registration in OrcTargetProcess. The current implementation only covers ELF on x86-64, but the infrastructure is not limited to that.

The journey starts with a new `LinkGraph` / `JITLinkContext` pair being created for a `MaterializationResponsibility` in ORC's `ObjectLinkingLayer`. It sends a `notifyMaterializing()` notification, which is forwarded to all registered plugins. The `DebugObjectManagerPlugin` aims to create a `DebugObject` form the provided target triple and object buffer. (Future implementations might create `DebugObject`s from a `LinkGraph` in other ways.) On success it will track it as the pending `DebugObject` for the `MaterializationResponsibility`.

This patch only implements the `ELFDebugObject` for `x86-64` targets. It follows the RuntimeDyld approach for debug object setup: it captures a copy of the input object, parses all section headers and prepares to patch their load-address fields with their final addresses in target memory. It instructs the plugin to report the section load-addresses once they are available. The plugin overrides `modifyPassConfig()` and installs a JITLink post-allocation pass to capture them.

Once JITLink emitted the finalized executable, the plugin emits and registers the `DebugObject`. For emission it requests a new `JITLinkMemoryManager::Allocation` with a single read-only segment, copies the object with patched section load-addresses over to working memory and triggers finalization to target memory. For registration, it notifies the `DebugObjectRegistrar` provided in the constructor and stores the previously pending`DebugObject` as registered for the corresponding MaterializationResponsibility.

The `DebugObjectRegistrar` registers the `DebugObject` with the target process. `llvm-jitlink` uses the `TPCDebugObjectRegistrar`, which calls `llvm_orc_registerJITLoaderGDBWrapper()` in the target process via `TargetProcessControl` to emit a `jit_code_entry` compatible with the GDB JIT interface [1]. So far the implementation only supports registration and no removal. It appears to me that it wouldn't raise any new design questions, so I left this as an addition for the near future.

[1] https://sourceware.org/gdb/current/onlinedocs/gdb/JIT-Interface.html

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D97335

show more ...