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

[Peter Collingbourne via llvm-commits]

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.

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

Thanks,
-- 
Peter