[PATCH] D68465: [DebugInfo] Trim call-clobbered location list entries when tuning for GDB

Tue Oct 8 13:15:02 PDT 2019

dblaikie added a comment.

In D68465#1699862 <https://reviews.llvm.org/D68465#1699862>, @probinson wrote:

> In D68465#1698682 <https://reviews.llvm.org/D68465#1698682>, @dblaikie wrote:
>
> > In D68465#1697824 <https://reviews.llvm.org/D68465#1697824>, @probinson wrote:
> >
> > > @dblaikie I'm also not clear what you're suggestion about .debug_addr entry plus offset.  DW_LLE_offset_pair does this, derived from the base address, which ought to be available for any given function, assuming DWARF v5.  Can you explain more clearly what's missing?
> >
> >
> > My point was generally that the debug_addr section shouldn't be incnluding addresses with offsets, it should be the places that refer to debug_addr that use the offsets. The specific place I'd like to use offsets would be from FORM_addr in debug_info. But, yes, in this case the support for debug addr references from loclists, the forms are already sufficiently descriptive for this.
>
>
> Ah, got it.  The problem you're facing is that for a DIE, a FORM describes one value, while you want to describe two--the address (or index into .debug_addr), and a separate offset.  For a DIE attribute, this would normally be done using an expression.  Would it work to have (say) DW_AT_low_pc be allowed to have class exprloc?  (It currently must have class address, either FORM_addr or one of the FORM_addrx's.)  The expression can index into .debug_addr and then add an offset to the result.

Yep, we've (you, me, DWARF committee, other folks) have talked about it before, years ago - didn't mean to derail/rehash the whole thing. I've prototyped it with expressions - you're right, doesn't require much change to the DWARF standard (if any, really - DWARF being permissive & all) but maybe a fair bit of chaneg/work for DWARF consumers compared to a more specific encoding (& I'd previously asked/discussed what encoding would be suitable - given that both the address and teh offset support various different fixed (& then variable) length encodings and having the combination of all of those would be painful - so having only the 2xuleb encoding was the last thing discussed).

But, yeha, once we've got DWARFv5 fully implemented & deployed/functioning with LLDB and GDB I'll probably look at whether addr+offset is worthwhile. (the other, sort of cheaper workaround, is to use a rnglist of length 1 - not sure how much the addr+offset would save compared to a rnglist of length 1, etc - lots to compare, see what's worthwhile)

Repository:
  rL LLVM

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

https://reviews.llvm.org/D68465