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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D81144#2075322 <https://reviews.llvm.org/D81144#2075322>, @MaskRay wrote:

> In D81144#2075259 <https://reviews.llvm.org/D81144#2075259>, @ikudrin wrote:
>
> > The thing is, where the generated debugging info will be eventually placed by a linker. They usually tend to place sections in a similar order as input files, so that small object file, compiled from an assembly, with 32-bit debug info, may easily come after other files with huge debugging info, resulting in impossibility to relocate 32-bit offsets in that small file correctly. The linker should be smart enough to adjust the order of debug info sections in order to avoid that. Not sure if there is any linker that does that.
>


Oh, good point - you're talking about the sec_offsets - like the sec_offset to the line table, or abbrev, or the debug_str section... yeah, fair point, even if a single .o files contributions are small, those contributions may still need large encodings for the sec_offsets used between DWARF sections - and thus needing DWARF64.

> If the linker places huge_c.o:.text before asm.o:.text, it would be weird if the linker places asm.o:.debug_info before huge_c.o:.debug_info
>  A linker can be smarter, but the output will be unexpected.

The relative order between the .text and the .debug_info shouldn't be an issue - I think it's more the absolute size of any debug info section that needs a sec_offset reference to it. (debug_info can use sec_offset refer to debug_info (though our assembly support never needs this), debug_info uses sec_offsets to refer to all the other sections - abbrev, str, str_offsets, loc/loclists, range/rnglists, etc... (except aranges - which refers to the CU instead - so it might need 64 bit encodings for that reference)).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81144