[WIP] Implement JITLoaderGDB ObjectLinkingLayer plugin for ELF x86-64

[sgraenitz]

Summary

First proposal for debugging support in JITLink. For now, only in-process x86-64 ELF. Please consider it a work-in-progress.

The JITLinkGDBLoaderPlugin forwards object files from ObjectLinkingLayer to an attached debugger through the GDB JIT Interface [1]. It implements ObjectLinkingLayer::Plugin::notifyLoaded() and expects an additional argument: a callback function that prepares a in-memory debug object for the given MaterializationResponsibility on request. The patch aims to keep overhead in generic execution paths minimal. Additional efforts for debug registration should reside in the callback.

Furthermore, responsibility for the preparation of the actual debug object buffer lies with the respective JITLink backend, so we can keep all format/architecture-specific code in one place. In this first sketch it's accomplished with another callback from linkPhase1 to the backend. While the JITLinkContext might be considered the natural owner of the function pointer, it is currently stored in the LinkGraph, because this is our only connection to the backend. The goal was to keep patch small and seek feedback first.

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

[sgraenitz]

This should work with the current state:

> cat jitbp.cpp
int jitbp() { return 0; }
int main() { return jitbp(); }
> clang -c -g -fPIC --target=x86_64-unknown-unknown-elf -o jitbp.o jitbp.cpp
> bin/lldb -o 'settings set plugin.jit-loader.gdb.enable on' -o 'b runAsMain' -o 'run jitbp.o' bin/llvm-jitlink
Process 65394 stopped
(lldb) b jitbp
Breakpoint 2: where = JIT(0x7ffff7fcd000)`jitbp() + 6 at jitbp.cpp:1:15, address = 0x00007ffff7fce006
(lldb) c
Process 65394 resuming
(lldb) Process 65394 stopped
* thread #1, name = 'llvm-jitlink', stop reason = breakpoint 2.1
    frame #0: 0x00007ffff7fce006 JIT(0x7ffff7fcd000)`jitbp() at jitbp.cpp:1:15
-> 1    int jitbp() { return 0; }
   2    int main() { return jitbp(); }

[lhames]

This is very exciting.

This is adopting RuntimeDyld's approach of patching section addresses to inform the debugger about final locations. I think this is ideal for a prototype, but probably not the right approach to the final version. I've only got two loosely formed thoughts on this so far:

(1) We shouldn't special-case the JITLinkContext callbacks except as a last resort. If we have to use them at all we should prefer making any information required available via generic structures like the LinkGraph. In this case I think you could build a SectionRange for each JITLink::Section rather than rely on the SegmentLayout.

(2) If we constructed the debug object file from scratch (rather than mutating the existing one) then we could

• support debug info for raw LinkGraphs (very attractive for long term performance -- avoids serializing / deserializing to objects),
• reduce memory usage by not redundantly representing non-debug sections in the debug object
• potentially dead strip debug info to further reduce memory overhead

Whether any of this is reasonable, and how much would it would be is another question. Probably time for me to learn some DWARF. :)

Dave -- do you have any immediate thoughts?

[sgraenitz]

Hi Lang, thanks for your feedback!

In D96627#2561402, @lhames wrote:

(2) If we constructed the debug object file from scratch (rather than mutating the existing one)

Let me see if I understand that right. At the moment LinkGraphBuilder skips DWARF sections in createNormalizedSections() so they will not appear in the linker's resulting target memory allocation. Instead we decide about requesting the debug object i the plugin after we built the LinkGraph and make a separate allocation for it. You propose that we could change that and let the LinkGraph prepare the debug sections in a format that could be passed to the debugger? The plugin could query the target memory addresses from the LinkGraph and pass them to the debugger.

I think we'd still need to patch section addresses to inform the debugger about final locations, but otherwise it sounds reasonable. We will need a way to tell the LinkGraphBuilder whether or not to include them (i.e. the ObjectLinkingLayer plugin is present/enabled or not) in order to avoid overhead in non-debug sessions right? ObjectLinkingLayer::emit() could accomplish it by passing a flag to createLinkGraphFromObject(), but I don't see a way to hook into it from a plugin context currently. How could we solve that?

(1) We shouldn't special-case the JITLinkContext callbacks except as a last resort.

We'd avoid the extra callback parameter in notifyLoaded(), but we'd need some other API function instead. Or would you propose not to use an ObjectLinkingLayer plugin altogether?

• support debug info for raw LinkGraphs (very attractive for long term performance -- avoids serializing / deserializing to objects),

Oh interesting. Thinking about synthetic debug info for compiler/linker injected code..

• reduce memory usage by not redundantly representing non-debug sections in the debug object

I think we could already strip them in the current approach. LLDB at least doesn't seem to touch it.

[lhames]

In D96627#2562274, @sgraenitz wrote:

Hi Lang, thanks for your feedback!

In D96627#2561402, @lhames wrote:

(2) If we constructed the debug object file from scratch (rather than mutating the existing one)

Let me see if I understand that right. At the moment LinkGraphBuilder skips DWARF sections in createNormalizedSections() so they will not appear in the linker's resulting target memory allocation. Instead we decide about requesting the debug object i the plugin after we built the LinkGraph and make a separate allocation for it. You propose that we could change that and let the LinkGraph prepare the debug sections in a format that could be passed to the debugger? The plugin could query the target memory addresses from the LinkGraph and pass them to the debugger.

That's not quite what I had in mind (though it's also something we could discuss).

What I meant was that right now RuntimeDyld copies the entire incoming object (text, data and all) then mutates the load addresses in the header and passes the resulting object to the debugger. What I'm suggesting is that we consider constructing a new object file (ELF, MachO, COFF) from scratch to hold the debug info that we want to pass to the debugger. This synthesized object file should (ideally) not need to carry anything but the headers and debug info. How we transport that to the target process would be a separate question.

I think we'd still need to patch section addresses to inform the debugger about final locations, but otherwise it sounds reasonable.

In the scheme I'm suggesting we'd just be synthesizing new load commands for the sections in the LinkGraph. This would be a post-allocation pass, so we could inspect the graph to see where each section referred to by the debug info starts and ends.

We will need a way to tell the LinkGraphBuilder whether or not to include them (i.e. the ObjectLinkingLayer plugin is present/enabled or not) in order to avoid overhead in non-debug sessions right? ObjectLinkingLayer::emit() could accomplish it by passing a flag to createLinkGraphFromObject(), but I don't see a way to hook into it from a plugin context currently. How could we solve that?

I think the aim would be that we just don't install the debugging support plugin if debugging is not enabled.

(1) We shouldn't special-case the JITLinkContext callbacks except as a last resort.

We'd avoid the extra callback parameter in notifyLoaded(), but we'd need some other API function instead. Or would you propose not to use an ObjectLinkingLayer plugin altogether?

No, this should definitely be an object linking layer plugin, but I think we should be synthesizing / modifying the debug object in a jitlink pass installed by the plugin. That's the way EH-frame registration now works in the runtime prototype: https://github.com/lhames/llvm-project/blob/315f9f15e7233a5c956022201ac898f94196802a/llvm/lib/ExecutionEngine/Orc/MachOPlatform.cpp#L825 .

• support debug info for raw LinkGraphs (very attractive for long term performance -- avoids serializing / deserializing to objects),

Oh interesting. Thinking about synthetic debug info for compiler/linker injected code..

Exactly. One day

• reduce memory usage by not redundantly representing non-debug sections in the debug object

I think we could already strip them in the current approach. LLDB at least doesn't seem to touch it.

Yeah. I think we're converging on the same solution from different ends: You can think of this as stripping the incoming object back to contain only what's needed for the debugger, or you can think of it as building up a new object (using some source of debug info) for the debugger. The latter generalizes to support debug info in LinkGraphs.

If we take the synthesizing-a-new-object approach it means that we'll need to represent the debug info in the graphs, at least initially. I guess a sketch of the approach would look like this:

1. LinkGraphBuilders stop skipping debug info (this adds some overhead in the case where objects have debug info, but debug info is not used by the JIT. I think that's tolerable for now, we can revisit later if we want to make this optional).
2. JITLinkGDBLoaderPlugin installs two plugins that cooperate to synthesize and register a debug object:
   1. A pre-allocation pass synthesizes a debug object by copying the data out of the debug sections in the graph. In the synthesized object section and symbol target addresses are initially zero. The pass then deletes the debug sections from the graph.
   2. A post-allocation pass mutates the synthesized debug object based on the final target addresses in the graph. It then calls the runtime to register the debug info with the gdb registration API.

Does that sound reasonable?

[sgraenitz]

In D96627#2562565, @lhames wrote:

we should be synthesizing / modifying the debug object in a jitlink pass installed by the plugin

Aha, plugins can install linker passes! I didn't give enough attention to this. Sounds like it could make some extra infra in the current proposal obsolete (i.e. the callback and from the plugin to the linker driver).

1. LinkGraphBuilders stop skipping debug info (this adds some overhead in the case where objects have debug info, but debug info is not used by the JIT. I think that's tolerable for now, we can revisit later if we want to make this optional).
2. JITLinkGDBLoaderPlugin installs two plugins that cooperate to synthesize and register a debug object:
   1. A pre-allocation pass synthesizes a debug object by copying the data out of the debug sections in the graph. In the synthesized object section and symbol target addresses are initially zero. The pass then deletes the debug sections from the graph.
   2. A post-allocation pass mutates the synthesized debug object based on the final target addresses in the graph. It then calls the runtime to register the debug info with the gdb registration API.

Does that sound reasonable?

Yes, I will have a look at the API to install linker passes and see how far I come.

[dblaikie]

In D96627#2561402, @lhames wrote:

This is very exciting.

This is adopting RuntimeDyld's approach of patching section addresses to inform the debugger about final locations. I think this is ideal for a prototype, but probably not the right approach to the final version. I've only got two loosely formed thoughts on this so far:

(1) We shouldn't special-case the JITLinkContext callbacks except as a last resort. If we have to use them at all we should prefer making any information required available via generic structures like the LinkGraph. In this case I think you could build a SectionRange for each JITLink::Section rather than rely on the SegmentLayout.

(2) If we constructed the debug object file from scratch (rather than mutating the existing one) then we could

• support debug info for raw LinkGraphs (very attractive for long term performance -- avoids serializing / deserializing to objects),
• reduce memory usage by not redundantly representing non-debug sections in the debug object
• potentially dead strip debug info to further reduce memory overhead

Whether any of this is reasonable, and how much would it would be is another question. Probably time for me to learn some DWARF. :)

Dave -- do you have any immediate thoughts?

No immediate thoughts - happy to chat more about it, though. We might have to meet in the middle with regards to learning things here - I don't know too much about these JIT debugger APIs or what options they might have with regards to their input formats, resolution of addresses, etc.

[sgraenitz]

If we constructed the debug object file from scratch (rather than mutating the existing one)

While this sounds reasonable to me, it appears to add quite some effort. I guess we could grow our own writer that can emit in-memory ELF objects in some specific format, but there's a load of details that would need consideration sooner or later (recalculating offsets, compressed sections, etc.). Eventually, doing it right would probably mean something like llvm-objcopy --only-keep-debug. The implementation of it is buried with the tool implementation currently, so I can hardly "just use" it: https://reviews.llvm.org/rG5ad0103d8a04cb066dfae4fc20b0dfcd9413f4d4

What do you think?

(I will try a hack in the next days to see whether it's viable at all, but I'd would keep hopes low that we get there anytime soon.)

[lhames]

In D96627#2566871, @sgraenitz wrote:

If we constructed the debug object file from scratch (rather than mutating the existing one)

While this sounds reasonable to me, it appears to add quite some effort. I guess we could grow our own writer that can emit in-memory ELF objects in some specific format, but there's a load of details that would need consideration sooner or later (recalculating offsets, compressed sections, etc.). Eventually, doing it right would probably mean something like llvm-objcopy --only-keep-debug. The implementation of it is buried with the tool implementation currently, so I can hardly "just use" it: https://reviews.llvm.org/rG5ad0103d8a04cb066dfae4fc20b0dfcd9413f4d4

What do you think?

(I will try a hack in the next days to see whether it's viable at all, but I'd would keep hopes low that we get there anytime soon.)

I think MachOWriter and ELFWriter seem very useful outside llvm-objcopy. @MaskRay -- Do you think it would be reasonable to move those classes into a library? Maybe Object? Or BinaryFormat?

[MaskRay]

In D96627#2567468, @lhames wrote:

In D96627#2566871, @sgraenitz wrote:

If we constructed the debug object file from scratch (rather than mutating the existing one)

While this sounds reasonable to me, it appears to add quite some effort. I guess we could grow our own writer that can emit in-memory ELF objects in some specific format, but there's a load of details that would need consideration sooner or later (recalculating offsets, compressed sections, etc.). Eventually, doing it right would probably mean something like llvm-objcopy --only-keep-debug. The implementation of it is buried with the tool implementation currently, so I can hardly "just use" it: https://reviews.llvm.org/rG5ad0103d8a04cb066dfae4fc20b0dfcd9413f4d4

What do you think?

(I will try a hack in the next days to see whether it's viable at all, but I'd would keep hopes low that we get there anytime soon.)

I think MachOWriter and ELFWriter seem very useful outside llvm-objcopy. @MaskRay -- Do you think it would be reasonable to move those classes into a library? Maybe Object? Or BinaryFormat?

Hey. I am happy to share what I know about ELF, but I never look into jit in detail. (I should do that at some point..)

There is a feature request about "librarify llvm-objcopy": https://bugs.llvm.org/show_bug.cgi?id=41044
There was incomplete work in 2019. The latest attempt is https://lists.llvm.org/pipermail/llvm-dev/2021-January/147892.html (I haven't followed it).

As someone who implemented llvm-objcopy --only-keep-debug, I know that llvm-objcopy has two writers, one placing segments than sections, the other one (--only-keep-debug) placing sections then segments.
If you look at objcopy/llvm-objcopy --add-section and think it can do JIT job,,, you may get disappointed😓 The feature does not affect program headers (especially the most important PT_LOAD)...
so generally --add-section is probably only meaningful for relocatable object files (ET_REL) and non-SHF_ALLOC sections in executable and shared object files (ET_EXEC, ET_DYN).

With my current limited understanding about JIT, I think you may be able to take inspiration from some llvm-objcopy code, but using it as a library to do what you intend to do ... may be really difficult.

I think you can probably take more inspiration from the link editor LLD than llvm-objcopy... Placing sections & segments in a usable way is difficult. lld/ELF/Writer.cpp has fairly sophisticated (complicated) code doing that.

[sgraenitz]

In D96627#2567598, @MaskRay wrote:

Hey. I am happy to share what I know about ELF, but I never look into jit in detail. (I should do that at some point..)

Thanks for your pointers and estimation!

There is a feature request about "librarify llvm-objcopy": https://bugs.llvm.org/show_bug.cgi?id=41044
There was incomplete work in 2019. The latest attempt is https://lists.llvm.org/pipermail/llvm-dev/2021-January/147892.html (I haven't followed it).

Good to know that's basically in-progress already. It seems the overall refactoring in D88827 stagnated only because it requires some additional work in preparation (i.e. D91028 and D91693 which are both in active development). That's reinforcing my first impression: might be helpful, but it's a lot of work.

As someone who implemented llvm-objcopy --only-keep-debug, I know that llvm-objcopy has two writers, one placing segments than sections, the other one (--only-keep-debug) placing sections then segments.
If you look at objcopy/llvm-objcopy --add-section and think it can do JIT job,,, you may get disappointed😓 The feature does not affect program headers (especially the most important PT_LOAD)...
so generally --add-section is probably only meaningful for relocatable object files (ET_REL) and non-SHF_ALLOC sections in executable and shared object files (ET_EXEC, ET_DYN).

With my current limited understanding about JIT, I think you may be able to take inspiration from some llvm-objcopy code, but using it as a library to do what you intend to do ... may be really difficult.

JITLink does deal with relocatable object files (both, input and debug-output to LLDB), so maybe the functionality behind --add-section would be applicable in our case? However, I didn't have a closer look and it's really not something I'd want to judge.

Meanwhile, my quick hack is backing your thesis: I stripped my jitbp.o input object with llvm-objcopy --only-keep-debug on disk and fed that into LLDB as the debug-object for jitbp.o (including patched load-addresses for .text and .eh_frame). Now LLDB fails to calculate the correct address for the breakpoint site in my initial example:

(lldb) b jitbp
warning: failed to set breakpoint site at 0x6 for breakpoint 3.1: error: 9 sending the breakpoint request
Breakpoint 3: where = JIT(0x7ffff7fcd000)`jitbp() + 6 at jitbp.cpp:1:15, address = 0x0000000000000006

Maybe this is easy to fix. LLDB might just ignore .text sections of type NOBITS and so doesn't apply the load addresses or so, but given your concerns and my unfamiliarity with the code, I'd rather not debug that now. I'd say we keep the option in mind, let the refactoring land and consider it a task for further improvement.

BTW @MaskRay llvm-objcopy --only-keep-debug reduced the size of my minimal test object by only 128 byte (4%). That matches the size of .text plus .eh_frame, which disappeared (but yes, they still get reported in the headers). However, their relocation sections .rela.text and .rela.eh_frame still exist and occupy 90 additional bytes (3%). How are they required for debug?

[sgraenitz]

@lhames In my first proposal I used the ResourceKey value to identify a MaterializationResponsibility. Now I found that the EHFrameRegistrationPlugin uses ResourceKey and MaterializationResponsibility * as keys for different purposes (EHFrameRanges and InProcessLinks respectively).

Are there conceptual reasons for it? Any pros and cons?
Is the mapping between ResourceKey and MaterializationResponsibility always unique in both directions?

Thanks

[sgraenitz]

Add notifyMaterializing() handlers for Plugin and JITLinkContext. The JITLoaderGDBPlugin uses it to obtain a copy of the input object file, so we don't need to touch Plugin::notifyLoaded(). Furthermore the plugin uses a JITLink post-allocation pass to record section load-addresses in target memory. Instead of reaching out to the backend, it now applies format-specific transformations of the debug object itself based on the triple provided by the pass configuration.

[sgraenitz]

Unregistering, failure handling, tests and out-of-process support are still to do. I made some notes and highlighted current open questions inline.

Going forward, I think the most pressing question is testing. LLDB will have an end-to-end test, which checks that a JIT breakpoint in a minimal C++ file gets hit. It will cover all of the mandatory code paths. I am not sure though what's the best way to test cases with multiple MRs, splitting MRs, multi-threading, removing resources, etc. EHFrameRegistrationPlugin seems to have coverage for most of its code from LLJIT tests. Maybe that could be an option here too?

llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h

1352

New API function. The ObjectLinkingLayerJITLinkContext forwards it to the plugins. It feels quite symmetric to notifyFailed().

1400

New API function. Doesn't give the API client access to the underlying buffer.

llvm/include/llvm/ExecutionEngine/Orc/ObjectLinkingLayer.h

78

New API function. We don't really need the LinkGraph, but only providing the context seems weird.

llvm/lib/ExecutionEngine/JITLink/ELF_x86_64.cpp

338

In order to make the plugin usable, we have to "ProcessAllSections". The good news is that the pruning step in linkPhase1 seems to remove all this.

llvm/tools/llvm-jitlink/llvm-jitlink-gdb-loader.cpp

208

It's quite far away from this patch, but I had a look at JITDylib::delegate(). It splits a MR in two and it looks like they both share one tracker. That might break my code currently. For now, I kept tracking debug objects by ResourceKey here, because I can get them from a MR, but not the other way around.

291

TODO: lock_guard

346

I can't reach the ExecutionSession here and there is no Error return value. Any chance we can report that?

This is due to the "never have more than one pending debug object" restriction above. Otherwise there is no way to determine the right debug object for a MR in the modifyPassConfig() and notifyLoaded() handlers. Or am I missing something?

[sgraenitz]

Obtain reference to ExecutionSession in ctor and use it for error reporting

[sgraenitz]

llvm/tools/llvm-jitlink/llvm-jitlink-gdb-loader.cpp

346

Error reporting done. The "never have more than one pending debug object" restriction still holds.

[sgraenitz]

New proposal posted with D97335

llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp

Config.PostPrunePasses.push_back([this](jitlink::LinkGraph &G) -> Error {
       return Error::success();
     });
     Config.PostFixupPasses.push_back([this](jitlink::LinkGraph &G) -> Error {
       printLinkGraph(G, "After fixup:");
       return Error::success();
     });
   }
 
-  void notifyLoaded(MaterializationResponsibility &MR) override {
+  void
+  notifyLoaded(MaterializationResponsibility &MR,
+               ObjectLinkingLayer::GetDebugObjCallback GetDebugObj) override {
     dbgs() << "Loading object defining " << MR.getSymbols() << "\n";
   }
 
   Error notifyEmitted(MaterializationResponsibility &MR) override {
     dbgs() << "Emitted object defining " << MR.getSymbols() << "\n";
     return Error::success();
   }
 

llvm/include/llvm/ExecutionEngine/JITLink/ELF_x86_64.h

 /// Create a LinkGraph from an ELF/x86-64 relocatable object.
 ///
 /// Note: The graph does not take ownership of the underlying buffer, nor copy
 /// its contents. The caller is responsible for ensuring that the object buffer
 /// outlives the graph.
 Expected<std::unique_ptr<LinkGraph>>
 createLinkGraphFromELFObject_x86_64(MemoryBufferRef ObjectBuffer);
 
+/// ObjectBuffer refers to a WriteableMemoryBuffer
+Error patchSectionLoadAddressesInELFObject_x86_64(
+    MutableArrayRef<char> ObjBufferMem,
+    const jitlink::NameAddrMap &SectionsInTargetMemory);
+
 /// jit-link the given object buffer, which must be a ELF x86-64 object file.
 void link_ELF_x86_64(std::unique_ptr<LinkGraph> G,
                      std::unique_ptr<JITLinkContext> Ctx);
 
 /// Return the string name of the given ELF x86-64 edge kind.
 StringRef getELFX86RelocationKindName(Edge::Kind R);
 } // end namespace jitlink
 } // end namespace llvm
 
 #endif // LLVM_EXECUTIONENGINE_JITLINK_ELF_X86_64_H

llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h

private:
   uint64_t P2Align : 5;
   uint64_t AlignmentOffset : 57;
   Section &Parent;
   const char *Data = nullptr;
   size_t Size = 0;
   std::vector<Edge> Edges;
 };
 
+struct SegmentLayout {
+  using BlocksList = std::vector<Block *>;
+
+  BlocksList ContentBlocks;
+  BlocksList ZeroFillBlocks;
+};
+
+using SegmentLayoutMap = DenseMap<unsigned, SegmentLayout>;
+
 /// Describes symbol linkage. This can be used to make resolve definition
 /// clashes.
 enum class Linkage : uint8_t {
   Strong,
   Weak,
 };
 
 /// For errors and debugging output.
public:
   }
   uint64_t getSize() const { return getEnd() - getStart(); }
 
 private:
   Block *First = nullptr;
   Block *Last = nullptr;
 };
 
+// TODO: If we can move the debug-object callback to JITLinkContext,
+// we get rid of this too.
+using NameAddrMap = std::map<StringRef, JITTargetAddress>;
+using PrepareObjectForDebugFunction =
+    std::function<Error(MutableArrayRef<char>, const NameAddrMap &)>;
+
 class LinkGraph {
 private:
   using SectionList = std::vector<std::unique_ptr<Section>>;
   using ExternalSymbolSet = DenseSet<Symbol *>;
   using BlockSet = DenseSet<Block *>;
 
   template <typename... ArgTs>
   Addressable &createAddressable(ArgTs &&... Args) {
using block_iterator = nested_collection_iterator<const_section_iterator,
                                                     Block *, getSectionBlocks>;
 
   using const_block_iterator =
       nested_collection_iterator<const_section_iterator,
                                  Section::const_block_iterator, const Block *,
                                  getSectionConstBlocks>;
 
   LinkGraph(std::string Name, const Triple &TT, unsigned PointerSize,
-            support::endianness Endianness)
+            support::endianness Endianness,
+            PrepareObjectForDebugFunction PrepareDebugObjFunc = nullptr)
       : Name(std::move(Name)), TT(TT), PointerSize(PointerSize),
-        Endianness(Endianness) {}
+        Endianness(Endianness),
+        PrepareDebugObjFunc(std::move(PrepareDebugObjFunc)) {}
 
   /// Returns the name of this graph (usually the name of the original
   /// underlying MemoryBuffer).
   const std::string &getName() { return Name; }
 
   /// Returns the target triple for this Graph.
   const Triple &getTargetTriple() const { return TT; }
 
   /// Returns the pointer size for use in this graph.
   unsigned getPointerSize() const { return PointerSize; }
 
   /// Returns the endianness of content in this graph.
   support::endianness getEndianness() const { return Endianness; }
 
+  bool canPrepareObjectForDebug() const {
+    return static_cast<bool>(PrepareDebugObjFunc);
+  }
+
+  // TODO: It would be nice to move this to JITLinkContext, but it's
+  // instantiated in ObjectLinkingLayer::emit() and cannot reach the linker
+  // backends that provide the PrepareDebugObjFunc function.
+  Error prepareObjectForDebug(MutableArrayRef<char> ObjBuffer,
+                              const NameAddrMap &SectionsInTargetMemory) const {
+    assert(PrepareDebugObjFunc && "If we cannot transform we should be here");
+    return PrepareDebugObjFunc(ObjBuffer, SectionsInTargetMemory);
+  };
+
   /// Allocate a copy of the given string using the LinkGraph's allocator.
   /// This can be useful when renaming symbols or adding new content to the
   /// graph.
   StringRef allocateString(StringRef Source) {
     auto *AllocatedBuffer = Allocator.Allocate<char>(Source.size());
     llvm::copy(Source, AllocatedBuffer);
     return StringRef(AllocatedBuffer, Source.size());
   }
private:
 
   std::string Name;
   Triple TT;
   unsigned PointerSize;
   support::endianness Endianness;
   SectionList Sections;
   ExternalSymbolSet ExternalSymbols;
   ExternalSymbolSet AbsoluteSymbols;
+
+  PrepareObjectForDebugFunction PrepareDebugObjFunc;
 };
 
 /// Enables easy lookup of blocks by addresses.
 class BlockAddressMap {
 public:
   using AddrToBlockMap = std::map<JITTargetAddress, Block *>;
   using const_iterator = AddrToBlockMap::const_iterator;
 
public:
   /// Return the JITLinkDylib that this link is targeting, if any.
   const JITLinkDylib *getJITLinkDylib() const { return JD; }
 
   /// Return the MemoryManager to be used for this link.
   virtual JITLinkMemoryManager &getMemoryManager() = 0;
 
   /// Notify this context that linking failed.
   /// Called by JITLink if linking cannot be completed.
   virtual void notifyFailed(Error Err) = 0;
 
   /// Called by JITLink to resolve external symbols. This method is passed a
   /// lookup continutation which it must call with a result to continue the
   /// linking process.
   virtual void lookup(const LookupMap &Symbols,
                       std::unique_ptr<JITLinkAsyncLookupContinuation> LC) = 0;
 
   /// Called by JITLink once all defined symbols in the graph have been assigned
   /// their final memory locations in the target process. At this point the
   /// LinkGraph can be inspected to build a symbol table, however the block
   /// content will not generally have been copied to the target location yet.
   ///
   /// If the client detects an error in the LinkGraph state (e.g. unexpected or
   /// missing symbols) they may return an error here. The error will be
   /// propagated to notifyFailed and the linker will bail out.
-  virtual Error notifyResolved(LinkGraph &G) = 0;
+  virtual Error notifyResolved(LinkGraph &G,
+                               const SegmentLayoutMap &Layout) = 0;
 
   /// Called by JITLink to notify the context that the object has been
   /// finalized (i.e. emitted to memory and memory permissions set). If all of
   /// this objects dependencies have also been finalized then the code is ready
   /// to run.
   virtual void
   notifyFinalized(std::unique_ptr<JITLinkMemoryManager::Allocation> A) = 0;
 
public:
   /// Called by JITLink to modify the pass pipeline prior to linking.
   /// The default version performs no modification.
   virtual Error modifyPassConfig(const Triple &TT, PassConfiguration &Config);
 
 private:
   const JITLinkDylib *JD = nullptr;
 };
 
 /// Marks all symbols in a graph live. This can be used as a default,
 /// conservative mark-live implementation.
 Error markAllSymbolsLive(LinkGraph &G);
 
 /// Create a LinkGraph from the given object buffer.
 ///
 /// Note: The graph does not take ownership of the underlying buffer, nor copy
 /// its contents. The caller is responsible for ensuring that the object buffer
 /// outlives the graph.

llvm/include/llvm/ExecutionEngine/Orc/ObjectLinkingLayer.h

 ///
 /// Clients can use this class to add relocatable object files to an
 /// ExecutionSession, and it typically serves as the base layer (underneath
 /// a compiling layer like IRCompileLayer) for the rest of the JIT.
 class ObjectLinkingLayer : public ObjectLayer, private ResourceManager {
   friend class ObjectLinkingLayerJITLinkContext;
 
 public:
+  using GetDebugObjCallback =
+      std::function<Expected<std::unique_ptr<MemoryBuffer>>()>;
+
   /// Plugin instances can be added to the ObjectLinkingLayer to receive
   /// callbacks when code is loaded or emitted, and when JITLink is being
   /// configured.
   class Plugin {
   public:
     using JITLinkSymbolVector = std::vector<const jitlink::Symbol *>;
     using LocalDependenciesMap = DenseMap<SymbolStringPtr, JITLinkSymbolVector>;
 
     virtual ~Plugin();
     virtual void modifyPassConfig(MaterializationResponsibility &MR,
                                   const Triple &TT,
                                   jitlink::PassConfiguration &Config) {}
 
-    virtual void notifyLoaded(MaterializationResponsibility &MR) {}
+    virtual void notifyLoaded(MaterializationResponsibility &MR,
+                              GetDebugObjCallback GetDebugObj) {}
     virtual Error notifyEmitted(MaterializationResponsibility &MR) {
       return Error::success();
     }
     virtual Error notifyFailed(MaterializationResponsibility &MR) = 0;
     virtual Error notifyRemovingResources(ResourceKey K) = 0;
     virtual void notifyTransferringResources(ResourceKey DstKey,
                                              ResourceKey SrcKey) = 0;
 
     /// Return any dependencies that synthetic symbols (e.g. init symbols)
     /// have on locally scoped jitlink::Symbols. This is used by the
setAutoClaimResponsibilityForObjectSymbols(bool AutoClaimObjectSymbols) {
     return *this;
   }
 
 private:
   using AllocPtr = std::unique_ptr<jitlink::JITLinkMemoryManager::Allocation>;
 
   void modifyPassConfig(MaterializationResponsibility &MR, const Triple &TT,
                         jitlink::PassConfiguration &PassConfig);
-  void notifyLoaded(MaterializationResponsibility &MR);
+  void notifyLoaded(MaterializationResponsibility &MR,
+                    GetDebugObjCallback GetDebugObj);
   Error notifyEmitted(MaterializationResponsibility &MR, AllocPtr Alloc);
 
   Error handleRemoveResources(ResourceKey K) override;
   void handleTransferResources(ResourceKey DstKey, ResourceKey SrcKey) override;
 
   mutable std::mutex LayerMutex;
   jitlink::JITLinkMemoryManager &MemMgr;
   std::unique_ptr<jitlink::JITLinkMemoryManager> MemMgrOwnership;

llvm/lib/ExecutionEngine/JITLink/ELF_x86_64.cpp

for (auto &SecRef : sections) {
       // Skip Dwarf sections.
       if (isDwarfSection(*Name)) {
         LLVM_DEBUG({
           dbgs() << *Name
                  << " is a debug section: No graph section will be created.\n";
         });
         continue;
       }
 
       sys::Memory::ProtectionFlags Prot;
       if (SecRef.sh_flags & ELF::SHF_EXECINSTR) {
         Prot = static_cast<sys::Memory::ProtectionFlags>(sys::Memory::MF_READ |
                                                          sys::Memory::MF_EXEC);
       } else {
         Prot = static_cast<sys::Memory::ProtectionFlags>(sys::Memory::MF_READ |
                                                          sys::Memory::MF_WRITE);
       }
for (auto SecRef : sections) {
       }
     }
     return Error::success();
   }
 
 public:
   ELFLinkGraphBuilder_x86_64(StringRef FileName,
                              const object::ELFFile<object::ELF64LE> &Obj)
-      : G(std::make_unique<LinkGraph>(FileName.str(),
-                                      Triple("x86_64-unknown-linux"),
-                                      getPointerSize(Obj), getEndianness(Obj))),
+      : G(std::make_unique<LinkGraph>(
+            FileName.str(), Triple("x86_64-unknown-linux"), getPointerSize(Obj),
+            getEndianness(Obj), &patchSectionLoadAddressesInELFObject_x86_64)),
         Obj(Obj) {}
 
   Expected<std::unique_ptr<LinkGraph>> buildGraph() {
     // Sanity check: we only operate on relocatable objects.
     if (!isRelocatable())
       return make_error<JITLinkError>("Object is not a relocatable ELF");
 
     auto Secs = Obj.sections();
if (!ELFObj)
     return ELFObj.takeError();
 
   auto &ELFObjFile = cast<object::ELFObjectFile<object::ELF64LE>>(**ELFObj);
   return ELFLinkGraphBuilder_x86_64((*ELFObj)->getFileName(),
                                     ELFObjFile.getELFFile())
       .buildGraph();
 }
 
+LLVM_ELF_IMPORT_TYPES_ELFT(object::ELF64LE)
+
+Error patchSectionLoadAddressesInELFObject_x86_64(
+    MutableArrayRef<char> ObjBufferMem,
+    const jitlink::NameAddrMap &SectionsInTargetMemory) {
+
+  MemoryBufferRef ObjectBuffer(
+      StringRef(ObjBufferMem.data(), ObjBufferMem.size()), "");
+  auto ELFObj = object::ObjectFile::createELFObjectFile(ObjectBuffer);
+  if (!ELFObj)
+    return ELFObj.takeError();
+
+  auto &ELFObjFile = cast<object::ELFObjectFile<object::ELF64LE>>(**ELFObj);
+  const object::ELFFile<object::ELF64LE> &Obj = ELFObjFile.getELFFile();
+
+  auto Sections = Obj.sections();
+  if (!Sections)
+    return Sections.takeError();
+
+  for (auto &SecRef : *Sections) {
+    assert(SecRef.sh_addr == 0 && "Section load-address set already");
+    StringRef Name = cantFail(Obj.getSectionName(SecRef));
+    auto It = SectionsInTargetMemory.find(Name);
+    if (It != SectionsInTargetMemory.end()) {
+      // Overwrite the load-address location in ObjBufferMem.
+      Elf_Shdr *shdr =
+          const_cast<Elf_Shdr *>(reinterpret_cast<const Elf_Shdr *>(&SecRef));
+      shdr->sh_addr = static_cast<object::ELF64LE::uint>(It->second);
+    }
+  }
+
+  LLVM_DEBUG({
+    dbgs() << formatv("Section load-addresses in debug object {0:x}\n",
+                      pointerToJITTargetAddress(ObjBufferMem.data()));
+    for (auto &SecRef : *Sections) {
+      StringRef Name = cantFail(Obj.getSectionName(SecRef));
+      if (!Name.empty()) {
+        if (auto Addr = static_cast<object::ELF64LE::uint>(SecRef.sh_addr)) {
+          dbgs() << formatv("  {0:x16} {1}\n", Addr, Name);
+        } else {
+          dbgs() << formatv("                     {0}\n", Name);
+        }
+      }
+    }
+  });
+
+  return Error::success();
+}
+
 void link_ELF_x86_64(std::unique_ptr<LinkGraph> G,
                      std::unique_ptr<JITLinkContext> Ctx) {
   PassConfiguration Config;
 
   if (Ctx->shouldAddDefaultTargetPasses(G->getTargetTriple())) {
 
     Config.PrePrunePasses.push_back(EHFrameSplitter(".eh_frame"));
     Config.PrePrunePasses.push_back(EHFrameEdgeFixer(

llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.h

JITLinkerBase(std::unique_ptr<JITLinkContext> Ctx,
       : Ctx(std::move(Ctx)), G(std::move(G)), Passes(std::move(Passes)) {
     assert(this->Ctx && "Ctx can not be null");
     assert(this->G && "G can not be null");
   }
 
   virtual ~JITLinkerBase();
 
 protected:
-  struct SegmentLayout {
-    using BlocksList = std::vector<Block *>;
-
-    BlocksList ContentBlocks;
-    BlocksList ZeroFillBlocks;
-  };
-
-  using SegmentLayoutMap = DenseMap<unsigned, SegmentLayout>;
-
   // Phase 1:
   //   1.1: Run pre-prune passes
   //   1.2: Prune graph
   //   1.3: Run post-prune passes
   //   1.4: Sort blocks into segments
   //   1.5: Allocate segment memory
   //   1.6: Identify externals and make an async call to resolve function
   void linkPhase1(std::unique_ptr<JITLinkerBase> Self);

llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.cpp

void JITLinkerBase::linkPhase1(std::unique_ptr<JITLinkerBase> Self) {
   // Run post-allocation passes.
   if (auto Err = runPasses(Passes.PostAllocationPasses))
     return Ctx->notifyFailed(std::move(Err));
 
   // Notify client that the defined symbols have been assigned addresses.
   LLVM_DEBUG(
       { dbgs() << "Resolving symbols defined in " << G->getName() << "\n"; });
 
-  if (auto Err = Ctx->notifyResolved(*G))
+  if (auto Err = Ctx->notifyResolved(*G, Layout))
     return Ctx->notifyFailed(std::move(Err));
 
   auto ExternalSymbols = getExternalSymbolNames();
 
   LLVM_DEBUG({
     dbgs() << "Issuing lookup for external symbols for " << G->getName()
            << " (may trigger materialization/linking of other graphs)...\n";
   });

 
 Error JITLinkerBase::runPasses(LinkGraphPassList &Passes) {
   for (auto &P : Passes)
     if (auto Err = P(*G))
       return Err;
   return Error::success();
 }
 
-JITLinkerBase::SegmentLayoutMap JITLinkerBase::layOutBlocks() {
-
+SegmentLayoutMap JITLinkerBase::layOutBlocks() {
   SegmentLayoutMap Layout;
 
   /// Partition blocks based on permissions and content vs. zero-fill.
   for (auto *B : G->blocks()) {
     auto &SegLists = Layout[B->getSection().getProtectionFlags()];
     if (!B->isZeroFill())
       SegLists.ContentBlocks.push_back(B);
     else

llvm/lib/ExecutionEngine/Orc/ObjectLinkingLayer.cpp

 //===------- ObjectLinkingLayer.cpp - JITLink backed ORC ObjectLayer ------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "llvm/ExecutionEngine/Orc/ObjectLinkingLayer.h"
 
 #include "llvm/ADT/Optional.h"
 #include "llvm/ExecutionEngine/JITLink/EHFrameSupport.h"
+#include "llvm/ExecutionEngine/JITLink/JITLink.h"
+#include "llvm/Support/Process.h"
 
 #include <vector>
 
 #define DEBUG_TYPE "orc"
 
 using namespace llvm;
 using namespace llvm::jitlink;
 using namespace llvm::orc;
void lookup(const LookupMap &Symbols,
 
     ES.lookup(LookupKind::Static, LinkOrder, std::move(LookupSet),
               SymbolState::Resolved, std::move(OnResolve),
               [this](const SymbolDependenceMap &Deps) {
                 registerDependencies(Deps);
               });
   }
 
-  Error notifyResolved(LinkGraph &G) override {
+  Error notifyResolved(LinkGraph &G, const SegmentLayoutMap &Layout) override {
     auto &ES = Layer.getExecutionSession();
 
     SymbolFlagsMap ExtraSymbolsToClaim;
     bool AutoClaim = Layer.AutoClaimObjectSymbols;
 
     SymbolMap InternedResult;
     for (auto *Sym : G.defined_symbols())
       if (Sym->hasName() && Sym->getScope() != Scope::Local) {
if (!ExtraSymbolsToClaim.empty())
       if (!ExtraSymbols.empty())
         return make_error<UnexpectedSymbolDefinitions>(G.getName(),
                                                        std::move(ExtraSymbols));
     }
 
     if (auto Err = MR->notifyResolved(InternedResult))
       return Err;
 
-    Layer.notifyLoaded(*MR);
+    ObjectLinkingLayer::GetDebugObjCallback GetDebugObjFunc = nullptr;
+    if (ObjBuffer && G.canPrepareObjectForDebug())
+      GetDebugObjFunc = [&]() {
+        return transformDebugObj(*ObjBuffer, G, Layout);
+      };
+
+    Layer.notifyLoaded(*MR, GetDebugObjFunc);
+
     return Error::success();
   }
 
   void notifyFinalized(
       std::unique_ptr<JITLinkMemoryManager::Allocation> A) override {
     if (auto Err = Layer.notifyEmitted(*MR, std::move(A))) {
       Layer.getExecutionSession().reportError(std::move(Err));
       MR->failMaterialization();
for (auto &NamedDepsEntry : ExternalNamedSymbolDeps) {
         if (DepsForJD.empty())
           SymbolDeps.erase(&SourceJD);
       }
 
       MR->addDependencies(Name, SymbolDeps);
     }
   }
 
+  Expected<MutableArrayRef<char>> allocateDebugObj(StringRef ObjMem) {
+    // TODO: We probably want to allow multiple allocs per JITLinkContext.
+    if (DebugObjAlloc)
+      return make_error<StringError>(
+          formatv("Failed to initialize debug object: JITLinkContext for has "
+                  "an associated debug object already"),
+          inconvertibleErrorCode());
+
+    // TODO: This works, but what alignment requirements do we actually have?
+    unsigned Alignment = sys::Process::getPageSizeEstimate();
+    unsigned ReadWrite = sys::Memory::MF_READ | sys::Memory::MF_WRITE;
+
+    Expected<std::unique_ptr<JITLinkMemoryManager::Allocation>> AllocOrErr =
+        Layer.MemMgr.allocate(&MR->getTargetJITDylib(),
+                              {{ReadWrite, {Alignment, ObjMem.size(), 0}}});
+    if (!AllocOrErr)
+      return AllocOrErr.takeError();
+    DebugObjAlloc = std::move(*AllocOrErr);
+
+    MutableArrayRef<char> DebugObjMem = DebugObjAlloc->getWorkingMemory(
+        static_cast<sys::Memory::ProtectionFlags>(ReadWrite));
+    memcpy(DebugObjMem.data(), ObjMem.data(), ObjMem.size());
+
+    return DebugObjMem;
+  }
+
+  Expected<std::unique_ptr<MemoryBuffer>>
+  transformDebugObj(const MemoryBuffer &ObjBuffer, const LinkGraph &G,
+                    const SegmentLayoutMap &Layout) {
+
+    Expected<MutableArrayRef<char>> DebugObjMem =
+        allocateDebugObj(ObjBuffer.getBuffer());
+    if (!DebugObjMem)
+      return DebugObjMem.takeError();
+
+    std::map<StringRef, JITTargetAddress> SectionLoadAddresses;
+    for (auto &KV : Layout) {
+      for (Block *B : KV.second.ContentBlocks)
+        SectionLoadAddresses[B->getSection().getName()] = B->getAddress();
+      for (Block *B : KV.second.ZeroFillBlocks)
+        SectionLoadAddresses[B->getSection().getName()] = B->getAddress();
+    }
+
+    if (Error Err = G.prepareObjectForDebug(*DebugObjMem, SectionLoadAddresses))
+      return std::move(Err);
+
+    StringRef Name = ObjBuffer.getBufferIdentifier();
+    StringRef MemRange(DebugObjMem->data(), DebugObjMem->size());
+    return MemoryBuffer::getMemBuffer(MemRange, Name, false);
+  }
+
   ObjectLinkingLayer &Layer;
   std::unique_ptr<MaterializationResponsibility> MR;
   std::unique_ptr<MemoryBuffer> ObjBuffer;
+  std::unique_ptr<JITLinkMemoryManager::Allocation> DebugObjAlloc;
   DenseMap<SymbolStringPtr, SymbolNameSet> ExternalNamedSymbolDeps;
   DenseMap<SymbolStringPtr, SymbolNameSet> InternalNamedSymbolDeps;
 };
 
 ObjectLinkingLayer::Plugin::~Plugin() {}
 
 ObjectLinkingLayer::ObjectLinkingLayer(ExecutionSession &ES,
                                        JITLinkMemoryManager &MemMgr)

 
 void ObjectLinkingLayer::modifyPassConfig(MaterializationResponsibility &MR,
                                           const Triple &TT,
                                           PassConfiguration &PassConfig) {
   for (auto &P : Plugins)
     P->modifyPassConfig(MR, TT, PassConfig);
 }
 
-void ObjectLinkingLayer::notifyLoaded(MaterializationResponsibility &MR) {
+void ObjectLinkingLayer::notifyLoaded(MaterializationResponsibility &MR,
+                                      GetDebugObjCallback GetDebugObj) {
   for (auto &P : Plugins)
-    P->notifyLoaded(MR);
+    P->notifyLoaded(MR, GetDebugObj);
 }
 
 Error ObjectLinkingLayer::notifyEmitted(MaterializationResponsibility &MR,
                                         AllocPtr Alloc) {
   Error Err = Error::success();
   for (auto &P : Plugins)
     Err = joinErrors(std::move(Err), P->notifyEmitted(MR));
 

llvm/tools/llvm-jitlink/CMakeLists.txt

set(LLVM_LINK_COMPONENTS
   RuntimeDyld
   Support
   )
 
 add_llvm_tool(llvm-jitlink
   llvm-jitlink.cpp
   llvm-jitlink-elf.cpp
   llvm-jitlink-macho.cpp
+  llvm-jitlink-gdb-loader.cpp
   )
 
 export_executable_symbols(llvm-jitlink)

llvm/tools/llvm-jitlink/llvm-jitlink-gdb-loader.h

+#ifndef LLVM_TOOLS_LLVM_JITLINK_JITLINKGDBLOADERPLUGIN_H
+#define LLVM_TOOLS_LLVM_JITLINK_JITLINKGDBLOADERPLUGIN_H
+
+#include "llvm/ExecutionEngine/Orc/ObjectLinkingLayer.h"
+
+#include "llvm/ADT/DenseMap.h"
+#include "llvm/ExecutionEngine/Orc/Core.h"
+#include "llvm/ExecutionEngine/Orc/ObjectLinkingLayer.h"
+#include "llvm/Object/ObjectFile.h"
+#include "llvm/Support/MemoryBuffer.h"
+
+#include <memory>
+
+namespace llvm {
+
+struct jit_code_entry;
+
+class JITLinkGDBLoaderPlugin : public orc::ObjectLinkingLayer::Plugin {
+
+  struct RegisteredObjectInfo {
+    jit_code_entry *Entry;
+    std::unique_ptr<MemoryBuffer> ObjBuffer;
+  };
+
+  using RegisteredObjectsList = std::vector<RegisteredObjectInfo>;
+  using GetDebugObjCallback = orc::ObjectLinkingLayer::GetDebugObjCallback;
+
+public:
+  void notifyLoaded(orc::MaterializationResponsibility &MR,
+                    GetDebugObjCallback GetDebugObj) override;
+
+  Error notifyFailed(orc::MaterializationResponsibility &MR) override {
+    return Error::success();
+  }
+  Error notifyRemovingResources(orc::ResourceKey K) override {
+    return Error::success();
+  }
+  void notifyTransferringResources(orc::ResourceKey DstKey,
+                                   orc::ResourceKey SrcKey) override {}
+
+private:
+  DenseMap<orc::ResourceKey, RegisteredObjectsList> RegisteredObjectsMap;
+};
+
+} // namespace llvm
+
+#endif // LLVM_TOOLS_LLVM_JITLINK_JITLINKGDBLOADERPLUGIN_H

llvm/tools/llvm-jitlink/llvm-jitlink-gdb-loader.cpp

+#include "llvm-jitlink-gdb-loader.h"
+
+#include "llvm/Support/ManagedStatic.h"
+
+#include <cstdint>
+#include <mutex>
+
+using namespace llvm::object;
+using namespace llvm::orc;
+
+namespace llvm {
+
+// This must be kept in sync with gdb/gdb/jit.h .
+extern "C" {
+
+typedef enum {
+  JIT_NOACTION = 0,
+  JIT_REGISTER_FN,
+  JIT_UNREGISTER_FN
+} jit_actions_t;
+
+struct jit_code_entry {
+  struct jit_code_entry *next_entry;
+  struct jit_code_entry *prev_entry;
+  const char *symfile_addr;
+  uint64_t symfile_size;
+};
+
+struct jit_descriptor {
+  uint32_t version;
+  // This should be jit_actions_t, but we want to be specific about the
+  // bit-width.
+  uint32_t action_flag;
+  struct jit_code_entry *relevant_entry;
+  struct jit_code_entry *first_entry;
+};
+
+// We put information about the JITed function in this global, which the
+// debugger reads.  Make sure to specify the version statically, because the
+// debugger checks the version before we can set it during runtime.
+struct jit_descriptor __jit_debug_descriptor = {1, 0, nullptr, nullptr};
+
+// Debuggers that implement the GDB JIT interface put a special breakpoint in
+// this function.
+LLVM_ATTRIBUTE_NOINLINE void __jit_debug_register_code() {
+  // The noinline and the asm prevent calls to this function from being
+  // optimized out.
+#if !defined(_MSC_VER)
+  asm volatile("" ::: "memory");
+#endif
+}
+}
+
+// Append an entry to the list in the JIT descriptor symbol and call the debug
+// trap function. TODO: Implement removal.
+void NotifyDebugger(jit_code_entry *JITCodeEntry) {
+  __jit_debug_descriptor.action_flag = JIT_REGISTER_FN;
+
+  // Insert this entry at the head of the list.
+  JITCodeEntry->prev_entry = nullptr;
+  jit_code_entry *NextEntry = __jit_debug_descriptor.first_entry;
+  JITCodeEntry->next_entry = NextEntry;
+  if (NextEntry) {
+    NextEntry->prev_entry = JITCodeEntry;
+  }
+  __jit_debug_descriptor.first_entry = JITCodeEntry;
+  __jit_debug_descriptor.relevant_entry = JITCodeEntry;
+  __jit_debug_register_code();
+}
+
+// JIT registration modifies global variables. Serialize them.
+ManagedStatic<std::mutex> JITDebugLock;
+
+void JITLinkGDBLoaderPlugin::notifyLoaded(MaterializationResponsibility &MR,
+                                          GetDebugObjCallback GetDebugObj) {
+  // Not all object types support debugging (yet).
+  if (!GetDebugObj)
+    return;
+
+  // Obtain an object buffer with patched load addresses for all sections.
+  Expected<std::unique_ptr<MemoryBuffer>> DebugObj = GetDebugObj();
+  if (!DebugObj) {
+    MR.getExecutionSession().reportError(DebugObj.takeError());
+    return;
+  }
+
+  StringRef MemRange = (**DebugObj).getBuffer();
+  jit_code_entry *JITCodeEntry =
+      new jit_code_entry{nullptr, nullptr, MemRange.data(), MemRange.size()};
+
+  orc::ResourceKey Key;
+  if (auto Err = MR.withResourceKeyDo([&](orc::ResourceKey K) { Key = K; })) {
+    MR.getExecutionSession().reportError(std::move(Err));
+    return;
+  }
+
+  // Cover registry as well. A second mutex wouldn't pay off.
+  std::lock_guard<std::mutex> Lock(*JITDebugLock);
+  RegisteredObjectsMap[Key].push_back({JITCodeEntry, std::move(*DebugObj)});
+  NotifyDebugger(JITCodeEntry);
+}
+
+} // namespace llvm

llvm/tools/llvm-jitlink/llvm-jitlink.cpp

 //===- llvm-jitlink.cpp -- Command line interface/tester for llvm-jitlink -===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // This utility provides a simple command line interface to the llvm jitlink
 // library, which makes relocatable object files executable in memory. Its
 // primary function is as a testing utility for the jitlink library.
 //
 //===----------------------------------------------------------------------===//
 
 #include "llvm-jitlink.h"
 
+#include "llvm-jitlink-gdb-loader.h"
+
 #include "llvm/BinaryFormat/Magic.h"
 #include "llvm/ExecutionEngine/Orc/ExecutionUtils.h"
 #include "llvm/ExecutionEngine/Orc/TPCDynamicLibrarySearchGenerator.h"
 #include "llvm/ExecutionEngine/Orc/TPCEHFrameRegistrar.h"
 #include "llvm/MC/MCAsmInfo.h"
 #include "llvm/MC/MCContext.h"
 #include "llvm/MC/MCDisassembler/MCDisassembler.h"
 #include "llvm/MC/MCInstPrinter.h"
else {
     return;
   }
 
   if (!NoExec && !this->TPC->getTargetTriple().isOSWindows())
     ObjLayer.addPlugin(std::make_unique<EHFrameRegistrationPlugin>(
         ES, ExitOnErr(TPCEHFrameRegistrar::Create(*this->TPC))));
 
   ObjLayer.addPlugin(std::make_unique<JITLinkSessionPlugin>(*this));
+  ObjLayer.addPlugin(std::make_unique<JITLinkGDBLoaderPlugin>());
 
   // Process any harness files.
   for (auto &HarnessFile : TestHarnesses) {
     HarnessFiles.insert(HarnessFile);
 
     auto ObjBuffer =
         ExitOnErr(errorOrToExpected(MemoryBuffer::getFile(HarnessFile)));