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

Thu Mar 21 03:26:07 PDT 2019

bd1976llvm added a comment.

In D59553#1437167 <https://reviews.llvm.org/D59553#1437167>, @ruiu wrote:

> 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.

Right; however, what if you didn't have to pay the cost in the object files. Sony has a lot of history/expertise in DWARF aware linking (rewriting). It is worth considering the benefits. A rule of thumb, developers tend to compile+link once but debug many times. Whilst the goal of DWARF that is transparent to the linker seems a nice idea... in reality a DWARF aware linker is in a position to create smaller optimized DWARF that improves the start up time of the debugger and improves the debugging experience in general. Overall this is a win for developer productivity - worth expending extra link time for. A further benefit of rewriting is that the emitted DWARF can be fully compatible with the DWARF standard; as opposed to relying on toolchain specific extensions. As a simple example: with --function-sections the .debug_line data for each function ends up emitted as a sub-program, delineated by a set address operation for the start and an end sequence marker for the end. This is an expensive representation. With knowledge of the final layout of the program the linker could emit a more efficient line program.

> 
> 
>> 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