Re: elfutils status 2009-07-07

[Roland McGrath <roland at redhat dot com>]

> Mostly reading Roland's sources and poking in dwarflint.  I expect more 
> of the latter this week.  I hope to replace the former with some actual 
> work.

The various dwarflint problems I cited seemed like they would be fairly
easy to fix.  It would be nice to get those done so that we have a clean
'make check' on gcc-4.4/F-11 (I don't think it emits any authentic bogons).

I haven't been commenting very well, and the structural mess of templatey
C++ can be pretty hard to follow.  Certainly ask early and often about
anything confusing.  There is definitely some stuff lurking around now that
is just unused cruft from some previous iteration of how I thought
something would go, and I have not tried to prune it, so there could be
some misleading rat holes in reading all the code.

There are two key structural things I'm currently hacking on in parallel.

One is the ref-handling, which really means all the fancy duplicate
consolidation of actual DIEs in the collector.  What's started there is on
roland/dwarf_output-tracker.  I think this might actually not block getting
output-writing to work, just block the actual compression part.  This is
probably too hairy to explain in much detail until I've gotten it going.

The other is the initial bookkeeping for abbrev generation.  I hacked a
little on roland/dwarf_output-shape for that, but I think now I'm going to
drop that tack and rejigger the dwarf_output::attributes_type construction
a different way.  I hope to get this new approach mostly done today/tonight.

It's this latter area that I think you can then pick up and start working
soon on some actual output generation pieces (finally!).

The work I'm doing now is on the "shape" stuff in the collector.  This
means that as a dwarf_output::debug_info_entry is created and its
attributes_type container goes into the collector, the collector will also
collect a set of unique "shapes".  A shape is almost an abbrev, but not
quite.  That is, it is the DIE tag + has-children flag + list of attribute
names and proto-forms + has-sibling flag.  A "proto-form" means "data" or
"block" or "ref" or "string", etc. but not yet distinguished to particular
encodings like data[124], string vs strp, etc.  The has-sibling flag means
whether this DIE has adjacent sibling DIEs or is the last of its parent's
children--this translates to whether or not we implicitly prepend a
{DW_AT_sibling,ref} to the attribute list in this shape.

I'll do the shape collection rolled into the debug_info_entry construction.
With that, format encoding of CUs in .debug_info can begin: just walk the
tree and emit.


Thanks,
Roland