On Thu, Jul 27, 2017 at 11:54 AM Robinson, Paul <paul.robin...@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
>
>
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
