[PATCH] D81144: [MC] Generate .debug_line in the 64-bit DWARF format [2/7]

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 9 08:12:29 PDT 2020


dblaikie added a comment.

In D81144#2082358 <https://reviews.llvm.org/D81144#2082358>, @probinson wrote:

> In D81144#2081485 <https://reviews.llvm.org/D81144#2081485>, @ikudrin wrote:
>
> > If an assembler source contains `.file`/`.loc` directives, and `-dwarf64` is given, `llvm-mc` will still correctly produce a `DWARF64` `.debug_line` section. That is because the only differences between `DWARF32` and `DWARF64` ones are `unit_length` and `header_length` fields, and references to `.debug_line_str`, and all these are covered by this patch.
> >
> > Do you have any specific example which results in an incorrect output with these patches?
>
>
> Right, both the GenDwarf and .file/.loc paths use the same infrastructure.  But if an assembler source contains .file/.loc directives, it likely also has compiler-generated .debug_info/etc sections, so the consistency of the output sections is not assured.  The DWARF spec (section 7.4) states "The 32-bit and 64-bit DWARF format conventions must _not_ be intermixed within a single compilation unit."
>
> Thinking about this more, as a practical matter, we probably don't want to make llvm-mc detect the formats of the .debug_info/etc sections and assure that all the formats are consistent.  I suppose have to make it the responsibility of the user to invoke llvm-mc with `--dwarf-64` only for hand-written asm or asm with other sections emitted in DWARF-64 format?


Yep, same way you have to (unfortunately) pass -gdwarf-5 when assembling a DWARF-having assembly file if you want a DWARFv5 line table (& in fact since DWARFv5 uses file zero, you have to do it if you want your assembler not to error-out). More of an issue for the actual clang integrated assembler than for llvm-mc, the latter is more of a tool for our LLVM developer convenience than an actual production assembler (so quirky interface issues are less of an issue here - but, yeah if there was some better solution for the production/user side, probably would consider using it for llvm-mc too).


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

https://reviews.llvm.org/D81144





More information about the llvm-commits mailing list