[Dwarf-Discuss] address pool + offset representation

[David Blaikie]

On Thu, Jul 27, 2017 at 11:54 AM Robinson, Paul <paul.robinson at sony.com>
wrote:

>
>                       |
> > I don't really know just how much LLDB cares about fixed-size forms/DIEs,
> > but rumor has it it's important to some degree, so I continue to have a
> > slight preference towards fixed size representations (or at least having
> > the option to do so, even if there are variable length forms too - as
> > with addrx).
>
> Greg Clayton has told me it's a performance win for loading .debug_info.
> They can index fixed-size DIEs without actually parsing them.  When I
> proposed the fixed-size strx/addrx forms to the committee, I did some
> data collection on the effect of strx and addrx.  Converting to strx
> meant fixed size DIEs went from 90-ish to 55-ish percent of all DIEs,
> so fixed-size strxN forms were definitely worthwhile.  The equivalent
> analysis for addrx showed a difference of more like 4%, which was
> enough to persuade the committee that would be worthwhile also.


I imagine the same would be true of ranges in an optimized build? (Maybe a
little lower, but not by much) 'spose, as you say, we can always add
rnglistxN in the future.


>   If
> we go with the low_pc-as-range idea then adding fixed-size versions of
> rnglistx in DWARF 6 would not be a problem.
>
> The advantage of what the ranges idea is it can all be done using
> exiting DWARF 5 features.
>

Yeah, for sure. Might well be the place for me to start - and certainly
something I could ship today (probably under a flag).

I was thinking that this optimization was an obvious enough win that there
might be interest in having a dedicated form for it - but OK proving it out
with another method like this first & then standardizing a
convenience/compact representation.


>
> > at that point I wouldn't mind a form that was two ULEBs (addrx + offset).
>
> Might as well just allow DW_AT_low_pc to use a location expression?
>   DW_OP_addrx <n> DW_OP_constx <offset> DW_OP_plus
> This would be way more acceptable than a new special-purpose form.
> Still bigger than a new form, of course, but as I noted above only 4%
> of DIEs become variable size so that penalty doesn't seem excessive.
> 3 bytes plus 3 LEBs, so only 3 bytes + 1 LEB more than the new form,
> and still cheaper than the ranges idea.
>

Oh, heh - funnily enough, this is /exactly/ how I prototyped it:

+  addUInt(Die, dwarf::DW_FORM_data1, dwarf::DW_OP_GNU_addr_index);
+  addUInt(Die, dwarf::DW_FORM_GNU_addr_index, IndexEntry.second);
+  if (IndexEntry.first != Label) {
+    addLabelDelta(Die, (dwarf::Attribute)0, Label, IndexEntry.first);
+    addUInt(Die, dwarf::DW_FORM_data1, dwarf::DW_OP_plus);
+  }

(Can certainly provide the full patch if you're curious)

I'm open to that - though it seemed like, while it'd be a small spec change
& obxviously low cost to producers (if they don't use the feature, costs
them nothing, and encoding this particular expression isn't
complicated/hard) - but might be really expensive for consumers to support
the full diversity of expressions in a new context? I could be wrong,
though.

- Dave

--paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20170727/f4c68c44/attachment-0001.htm>