<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 10:34 AM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Feb 18, 2016 at 09:30:52AM -0800, David Blaikie wrote:<br>
> On Wed, Feb 17, 2016 at 4:02 PM, Peter Collingbourne via llvm-commits <<br>
> <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
> > pcc added a comment.<br>
> ><br>
> > > The odd/even abbrev numbering seems a bit awkward - can we just build<br>
> > the new infrastructure closer to the old stuff, so they can pick numbers<br>
> > more closely?<br>
> ><br>
> ><br>
> > Maybe, but I'd like to avoid having the new code and the old code interact<br>
> > where possible. In particular, I think the code would be a little harder to<br>
> > unit test if I use the old code for abbreviations.<br>
> ><br>
><br>
> Fair - perhaps they could still share a counter, though, somehow. But maybe<br>
> not worth it. I wonder how novel out of order abbreviations are... (whether<br>
> it'll trip up any consumers)<br>
><br>
><br>
> ><br>
> > > (have you done any size analysis of this change - I realize the<br>
> > numbering of DIEs is probably a small component of DWARF size, but this<br>
> > change sounds like it'd increase DWARF size a little?)<br>
> ><br>
> ><br>
> > I'll see what the impact is on Chromium.<br>
> ><br>
> > > The abbreviation won't be known until the end of DWARF emission<br>
> ><br>
> ><br>
> > Is this true? Since the abbreviation depends only on the attribute names<br>
> > and forms, I suspect that in many cases we can compute an abbreviation up<br>
> > front and fill in attribute values later.<br>
> ><br>
> > For example, the abstract origins for concrete variables added by<br>
> > `DwarfDebug::finishVariableDefinitions`. Since we know at `DbgVariable`<br>
> > creation time whether a variable is concrete or not, we can create an<br>
> > abstract origin attribute with some arbitrary value for concrete variables<br>
> > when we create them (in the equivalent of<br>
> > `DwarfCompileUnit::constructVariableDIEImpl`), store a reference to that<br>
> > attribute somewhere (which could just be a `DIEData`+offset pair), and use<br>
> > that in `DwarfDebug::finishVariableDefinitions` to fill in the value.<br>
> ><br>
><br>
> It's not quite that simple - the reason finishVariableDefinitions (& other<br>
> similar things - this applies to subprograms, local variables, and some<br>
> local scopes) happens at the end is that we don't know at the time we see<br>
> the concrete definition whether we will see inline definitions as well.<br>
><br>
> Essentially the DWARF looks like:<br>
><br>
> subprogram<br>
> name<br>
> ...<br>
> high_pc<br>
> low_pc<br>
><br>
> if there's no inlining, but if there is inlining it looks like:<br>
><br>
> X: subprogram<br>
> name<br>
> ...<br>
><br>
> subprogram<br>
> abstract_origin X<br>
> high_pc<br>
> low_pc<br>
> ...<br>
><br>
> ...<br>
> inline_subroutine<br>
> abstract_origin X<br>
> high_pc<br>
> low_pc<br>
> ...<br>
><br>
> This is the only attribute case I know of (inlining - subprograms,<br>
> variables, and local scopes)- there are many cases where we don't know all<br>
> the children up-front. (implicit special members, nested types, local<br>
> scopes, any namespaces)<br>
<br>
</div></div>If abstract origins are the only attribute case then I think we can handle<br>
that with a special relocation that can insert an abstract origin. The<br>
relocation would store an offset (which would be the offset of the DIE)<br>
and the attribute value. We would process the relocation at emission time<br>
by looking up the abbreviation specification for the abbreviation number at<br>
the offset, prepending the attribute to the specfication, generating a new<br>
abbreviation number and replacing the old attribute number with the new one<br>
followed by the attribute value.<br></blockquote><div><br></div><div>Hmm, I'm not quite managing to picture what you're describing, I think.<br><br>Note that it's not just "does this tag have an abstract origin or not" but "either it has an abstract origin, or it has a bunch of other attributes (name, decl line, decl file, etc)"</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> What did you have in mind for unbounded children? keeping an insertion<br>
> point into the DWARF byte buffer & moving things out of the way to make<br>
> room for the missing children?<br>
<br>
</span>Yes, there would be insertion points, but I think it can be done without moving<br>
data at insertion time. Essentially I would want to add these fields to DIEData:<br>
<br>
uint64_t InsertAt;<br>
DIEData *FirstInsertion;<br>
DIEData *NextInsertion;<br>
<br>
To insert a DIE at an insertion point, we would push a DIEData onto the<br>
linked list at FirstInsertion, set InsertAt for the new DIEData to the<br>
insertion point, and keep track of it so any further DIE insertions would<br>
use the same DIEData. The DIEData::emit function would sort these insertions<br>
and emit them in the correct order.<br></blockquote><div><br></div><div>OK, I think I'm picturing that as you're describing it. Though I can't quite picture how that'll turn out in the end - I picture we'll still have a pretty deep hierarchy of DIEData, much like we have a hierarchy of DIEs today (granted, each would be smaller) and I'm just wondering if we might be better off keeping some of the more intentionally hierarchical parts of the existing design*, but I'm far from sure.<br><br>* that's more what I was picturing initially, just simplifying the DIEs so that they were bytes of DWARF, but still with the abbrev overhead of the existing design (so you could add new attributes/children to DIEs as we do today). Adding the optional ability to "bake" a child when you know you don't need to add anything to it (useful for the usual members of types (member functions, fields, etc)). But perhaps that's just a matter of opt-in versus opt-out & it's not too hard to opt-in for the DIEs we know have unbounded attributes and children.<br><br>(anyone else, feel free to chime in - Duncan, Adrian, Eric?)</div></div></div></div>