[PATCH] D92904: [lld-macho] Don't attempt to emit rebase opcodes for debug sections

[Jez Ng via Phabricator via llvm-commits]

int3 added a subscriber: clayborg.
int3 added a comment.

> I think "Fixes PR48392" is slightly more common

TIL about PR shortlinks. Thanks!

> I used -glldb. Does -ggdb create different sections?

It appears to omit a bunch of `__apple_*` sections, but `__debug_ranges` is present. But I as mentioned in the other comments, I don't think that section is critical to reproducing this bug.



================
Comment at: lld/MachO/Dwarf.cpp:24
+  for (InputSection *isec : obj->debugSections) {
+    if (StringRef *s = StringSwitch<StringRef *>(isec->name)
+                           .Case("__debug_info", &dObj->infoSection.Data)
----------------
tschuett wrote:
> thakis wrote:
> > I would find a comment here helpful why these are the `isDebugSection` sections that get a DwarfObject. It's not obvious to me why `__debug_line` and `__debug_ranges` aren't listed here (or why we do any filtering at all). I don't know much debug information and I can believe that it's obvious to domain experts :)
> llvm does not provide a isDwarfSection function?
I'm not a domain expert on debug info either, so maybe @clayborg can help fill in some details / correct any misconceptions :)

> It's not obvious to me why __debug_line and __debug_ranges aren't listed here (or why we do any filtering at all)

We filter out the debug sections because the debugger can locate the debug info via the STABS symbols that point to the corresponding source & object files. So all `lld` needs from the debug info is the source file path. Thus, I initialized the `DwarfObject` with just the sections that were required to obtain this info. `__debug_line` and `__debug_ranges` are presumably used by LLDB.

> llvm does not provide a isDwarfSection function?

Nope, or at least I haven't seen any that fits this use case.


================
Comment at: lld/test/MachO/stabs.s:141
 
 #--- foo.s
 .text
----------------
thakis wrote:
> Does this have "interesting enough" debug info? The `.o` file rom comment 8 in http://llvm.org/pr48392 :
> 
> ```
> $ out/gn/bin/llvm-objdump -h test.o | grep debug
>   4 __debug_abbrev   000000ae 0000000000000078 DATA
>   5 __debug_info     00000108 0000000000000126 DATA
>   6 __debug_ranges   00000040 000000000000022e DATA
>   7 __debug_str      0000009c 000000000000026e DATA
>  13 __debug_line     00000066 0000000000000540 DATA
> ```
> 
> This file:
> 
> ```
> $ out/gn/bin/llvm-objdump -h out/gn/obj/lld/test/MachO/Output/stabs.s.tmp/foo.o | grep debug
>   1 __debug_str    00000009 0000000000000001 DATA
>   2 __debug_abbrev 0000000c 000000000000000a DATA
>   3 __debug_info   00000021 0000000000000016 DATA
>   4 __debug_line   00000000 0000000000000037 DATA
> ```
> 
> (ie no `__debug_ranges`)
I don't think the presence of `__debug_ranges` is important to reproducing this bug. The important thing is the presence of `X86_64_RELOC_UNSIGNED` relocations that target debug sections, which are indeed generated by this test input.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92904