[PATCH] D80945: [DebugInfo] Fix a fatal error originating from split-macro support

[Sourabh Singh Tomar via Phabricator via llvm-commits]

SouraVX added a comment.

> I don't think this field (debug_line_offset) is optional if the debug_macro.dwo section contains DW_MACRO_start_file: "If a DW_MACRO_start_file entry is present, the header contains a reference to the .debug_line section of the compilation."

Yes, but spec seems a bit ambiguous in stating this. "If zero, that field is omitted. Pg. 166,  line 14-16", Not explicitly stating the fact/case where it should be always present.
And spec also doesn't say anything about explicit presence of `debug_line.dwo` when `debug_macro.dwo` is present, although it seems it should be present.

> I'm not entirely clear on how that's meant to work for Split DWARF - what does GCC do? Seems like this might have to, unfortunately duplicate more file names (same design limitation as DWARF type units, though) into .debug_line.dwo.

GCC(trunk) in non-split mode uses `*_strp`  and for split case uses some forms(Not available in v5). 
objdump(binutils 2.32) reports:

  objdump: Error:  Unknown macro opcode 22 seen
  objdump: Error:  Unknown macro opcode da seen

Anyways in ASM, it's clear that `debug_line_offset` referring to `debug_line_start` in `debug_line.dwo`. Dispensing relocation with a difference of labels(Start & End labels of debug_line.dwo section)

          .section        .debug_macro.dwo,"e", at progbits
  .Ldebug_macro0:
          .value  0x5
          .byte   0x2
          .long   .Lskeleton_debug_line0
          .byte   0x7
  ...
         .section        .debug_line.dwo,"e", at progbits
  .Lskeleton_debug_line0:
          .long   .LELT0-.LSLT0

I think if we want this then `debug_line.dwo` should be enabled first(Not always, but for type units and for macro info).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80945