[Dwarf-Discuss] address pool + offset representation
Wed Jul 26 19:17:32 GMT 2017
On Wed, Jul 26, 2017 at 12:00 PM Robinson, Paul <paul.robinson at sony.com>
> > From: Dwarf-Discuss [mailto:dwarf-discuss-bounces at lists.dwarfstd.org]
> On Behalf Of David Blaikie
> > Sent: Wednesday, July 26, 2017 11:04 AM
> > To: Doug Evans; dwarf-discuss at lists.dwarfstd.org
> > Subject: Re: [Dwarf-Discuss] address pool + offset representation
> > On Wed, Jul 26, 2017 at 10:51 AM Doug Evans <dje at google.com> wrote:
> >> How about a new form that specifies two things: index in .debug_addr +
> >> offset, where index and offset are any current constant representation
> >> (fixed size or leb) ?
> > Roughly what I had in mind - but wasn't sure how to encode that.
> > Would the type of the representation for each component be encoded at
> > the use? So this would be a variable length form (even when both the
> > index+offset use fixed length forms - because the form would be at the
> > use, so you'd have to read the bytes to figure out that they were using
> > fixed length forms)?
> > A two-value version of DW_FORM_indirect, I suppose?
> 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).
Certainly having a low_pc works like high_pc, but uses the nearest
enclosing low_pc would be a handy encoding size win as well, though, but I
was partly motivated by looking at what the actual minimum number of
relocations would be and looking at possible features/implementations that
would get all the way there.
> > I know the LLDB folks seem to find that fixed-width forms especially
> > help with parsing - not sure if GDB has a similar tendency/preference?
> The producer can pick a fixed-size constant form to accommodate this.
Not sure I quite follow - if the form is "pair of implicit values" then
that's the only form here. Inside the debug_info data, then there could be
constant forms for the two elements of the pair - but it's still a
dynamically sized form from the perspective of a parser.
Am I picturing this wrong?
> It would have to be a big-enough form, as the assembler would be
> computing the delta, but that's a QOI problem for the producer.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dwarf-discuss