[Dwarf-Discuss] address pool + offset representation
Wed Jul 26 21:31:53 GMT 2017
On Wed, Jul 26, 2017 at 12:56 PM Robinson, Paul <paul.robinson at sony.com>
> >> This discussion is about reducing the number of .debug_addr entries you
> >> need, so the place to look would be the "class address" attributes.
> >> There aren't all that many of them, and the one most likely to benefit
> >> would be DW_AT_low_pc.
> >> We made it okay to have DW_AT_high_pc be a constant, which is implicitly
> >> the sum of that constant with the same DIE's DW_AT_low_pc value.
> >> How about if DW_AT_low_pc could also be a constant, which would be added
> >> to the containing block/subprogram's DW_AT_low_pc?
> > It'd catch a fair few, maybe even most, of the cases - though still
> > potentially many more relocations than needed: eg: two (or more)
> > functions in the same section would end up using separate relocations
> > (assuming they were in a CU with at least one function in some other
> > section - such as an inline function in a comdat).
> Oh, because the unit wouldn't have a low_pc, it would have ranges?
> Well... why not just use ranges, in that case? .debug_rnglists is
> already tuned to reduce relocations. A range list with only one
> entry is the same as a contiguous range, and DW_RLE_offset_pair is
> basically the same as using constant low_pc and high_pc.
Fair point/question (I was going to say I wasn't sure if gdb supported
rnglists yet, but grepping the source it looks like it probably does -
though LLVM can't/doesn't produce them yet, it would be a good thing, even
aside from this particular issue).
Certainly would be a thing to prototype/a valid representation that would
reduce the number of address relocations/size of object files (under split
DWARF at least).
But I imagine that representation might be a bit larger overall/more
expensive to parse?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dwarf-discuss