[PATCH] D17321: DIEData, DIEWriter: introduce and begin migration.

[David Blaikie via llvm-commits]

On Thu, Feb 18, 2016 at 10:34 AM, Peter Collingbourne <peter at pcc.me.uk>
wrote:

> On Thu, Feb 18, 2016 at 09:30:52AM -0800, David Blaikie wrote:
> > On Wed, Feb 17, 2016 at 4:02 PM, Peter Collingbourne via llvm-commits <
> > llvm-commits at lists.llvm.org> wrote:
> >
> > > pcc added a comment.
> > >
> > > > The odd/even abbrev numbering seems a bit awkward - can we just build
> > > the new infrastructure closer to the old stuff, so they can pick
> numbers
> > > more closely?
> > >
> > >
> > > Maybe, but I'd like to avoid having the new code and the old code
> interact
> > > where possible. In particular, I think the code would be a little
> harder to
> > > unit test if I use the old code for abbreviations.
> > >
> >
> > Fair - perhaps they could still share a counter, though, somehow. But
> maybe
> > not worth it. I wonder how novel out of order abbreviations are...
> (whether
> > it'll trip up any consumers)
> >
> >
> > >
> > > > (have you done any size analysis of this change - I realize the
> > > numbering of DIEs is probably a small component of DWARF size, but this
> > > change sounds like it'd increase DWARF size a little?)
> > >
> > >
> > > I'll see what the impact is on Chromium.
> > >
> > > > The abbreviation won't be known until the end of DWARF emission
> > >
> > >
> > > Is this true? Since the abbreviation depends only on the attribute
> names
> > > and forms, I suspect that in many cases we can compute an abbreviation
> up
> > > front and fill in attribute values later.
> > >
> > > For example, the abstract origins for concrete variables added by
> > > `DwarfDebug::finishVariableDefinitions`. Since we know at `DbgVariable`
> > > creation time whether a variable is concrete or not, we can create an
> > > abstract origin attribute with some arbitrary value for concrete
> variables
> > > when we create them (in the equivalent of
> > > `DwarfCompileUnit::constructVariableDIEImpl`), store a reference to
> that
> > > attribute somewhere (which could just be a `DIEData`+offset pair), and
> use
> > > that in `DwarfDebug::finishVariableDefinitions` to fill in the value.
> > >
> >
> > It's not quite that simple - the reason finishVariableDefinitions (&
> other
> > similar things - this applies to subprograms, local variables, and some
> > local scopes) happens at the end is that we don't know at the time we see
> > the concrete definition whether we will see inline definitions as well.
> >
> > Essentially the DWARF looks like:
> >
> >   subprogram
> >     name
> >     ...
> >     high_pc
> >     low_pc
> >
> > if there's no inlining, but if there is inlining it looks like:
> >
> >   X: subprogram
> >     name
> >     ...
> >
> >   subprogram
> >     abstract_origin X
> >     high_pc
> >     low_pc
> >     ...
> >
> >   ...
> >   inline_subroutine
> >     abstract_origin X
> >     high_pc
> >     low_pc
> >     ...
> >
> > This is the only attribute case I know of (inlining - subprograms,
> > variables, and local scopes)- there are many cases where we don't know
> all
> > the children up-front. (implicit special members, nested types, local
> > scopes, any namespaces)
>
> If abstract origins are the only attribute case then I think we can handle
> that with a special relocation that can insert an abstract origin. The
> relocation would store an offset (which would be the offset of the DIE)
> and the attribute value. We would process the relocation at emission time
> by looking up the abbreviation specification for the abbreviation number at
> the offset, prepending the attribute to the specfication, generating a new
> abbreviation number and replacing the old attribute number with the new one
> followed by the attribute value.
>

Hmm, I'm not quite managing to picture what you're describing, I think.

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)"


>
> > What did you have in mind for unbounded children? keeping an insertion
> > point into the DWARF byte buffer & moving things out of the way to make
> > room for the missing children?
>
> Yes, there would be insertion points, but I think it can be done without
> moving
> data at insertion time. Essentially I would want to add these fields to
> DIEData:
>
> uint64_t InsertAt;
> DIEData *FirstInsertion;
> DIEData *NextInsertion;
>
> To insert a DIE at an insertion point, we would push a DIEData onto the
> linked list at FirstInsertion, set InsertAt for the new DIEData to the
> insertion point, and keep track of it so any further DIE insertions would
> use the same DIEData. The DIEData::emit function would sort these
> insertions
> and emit them in the correct order.
>

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.

* 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.

(anyone else, feel free to chime in - Duncan, Adrian, Eric?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160218/3e26deeb/attachment.html>