[PATCH] D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used

[Rui Ueyama via Phabricator via llvm-commits]

ruiu added a comment.

In D59553#1436941 <https://reviews.llvm.org/D59553#1436941>, @dblaikie wrote:

> In D59553#1436890 <https://reviews.llvm.org/D59553#1436890>, @probinson wrote:
>
> > Does this do the right thing for a 32-bit target?  64-bit is common, but not universal.
> >
> > Re. the underlying DWARF issues:
> >  I can't remember whether the DWARF committee has ever considered specifying a special value for "address does not exist" but I doubt it, because the DWARF spec states "If an entity has no associated machine code, none of these [address-related] attributes are specified." (DWARF v5 section 2.17, p.51.) So, the current position of the DWARF spec is that the linker is supposed to rewrite the DWARF, I guess.
>
>
> I don't think that's the intent of the DWARF standard/committee - it's been pretty careful about designing features that work with existing linker behavior without requiring the linker to be DWARF aware in any way.
>
> In D59553#1436899 <https://reviews.llvm.org/D59553#1436899>, @echristo wrote:
>
> > Likely the best way to solve this would be to put the debug information for the rest of it in the same section group as the function. In particular the subprogram die for the concrete function should be in a section group along with the function. This was part of the considerations with bringing other things back into the debug_info section in dwarf5 as well.
>
>
> I'd worry about the overhead of making hunks of standalone DIEs for every function. (though, that said - we do actually use 4 bytes for both a CU-relative offset, and for a sec_offset, I think - so maybe it doesn't matter /that/ much (adding a unit header would be the main cost - and maybe that's significant enough to be problematic size-wise too)).


Currently linkers don't eliminate debug info for garbage-collected sections, so the debug info for exectuables/shared objects are larger than necessary, so you could save bytes of the final output by using more bytes for intermediate object files. That doesn't seem like a bad deal to me.

> My guess, in the medium term, is that something like the approach proposed in this patch is likely reasonable - but I'd like to have more buy-in from all parties (emission, consumption, etc) around some blessed value to use to mark these things (& yeah, this does mean linker-awareness, though I think there's already some special cases in the linker around resolving these addresses to zero to begin with, maybe?).
> 
> & happy to be wrong here too - if we end up prototyping a "function units" equivalent of type units & seeing what the size overhead is, etc. (it'd be less problematic than type units at least - since there's no need for much/any DWARF to reference a function definition from elsewhere in the DWARF (unlike a type and its members, which all need to be referenced from elsewhere))




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

https://reviews.llvm.org/D59553