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

Wed Feb 17 03:16:57 PST 2021

sgraenitz added a comment.

In D96627#2567598 <https://reviews.llvm.org/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 <https://reviews.llvm.org/D88827> stagnated only because it requires some additional work in preparation (i.e. D91028 <https://reviews.llvm.org/D91028> and D91693 <https://reviews.llvm.org/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?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96627