[PATCH] D96627: [llvm-jitlink] Implement JITLoaderGDB ObjectLinkingLayer plugin for ELF x86-64

Sun Feb 14 06:35:25 PST 2021

sgraenitz added a comment.

Hi Lang, thanks for your feedback!

In D96627#2561402 <https://reviews.llvm.org/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.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96627/new/

https://reviews.llvm.org/D96627