dwarf_output status

[Roland McGrath <roland at redhat dot com>]

I've finally merged my output ref/tracker work, though it still has
issues.  I did a squash commit from my old branch, which is now stale.

What I think works now (except for bugs) is dwarf_output construction
with proper references, i.e. the reference iterators are valid and point
to the right places.  This includes constructing circular chains of
references.

What's still not done is making the duplicate-matching trigger when
circular references are involved.  I have a plan for that, but it will
wait until all the bugs are fixed first.  It will entail a little more
reorganization of some collector sets, but nothing too bad.

With dwarf_output as it is, I had three failures in dwarfcmp -T.  The
first was on libelf.so, which turned out to be all correct in the
dwarf_output construction.  In fact, it uncovered a subtle bug in the
comparator/tracker logic that could only have arisen because the
deduplication is working in the collector.

The other two failures are on dwarfcmp and dwarflint.  (That's never
surprising, the two with all the C++ and by far the largest CUs of all.)
The dwarflint case constructs happily but comparison fails on reference
mismatches.  I suspect that this is also a bug in the comparator/tracker
and nothing actually wrong in dwarf_output.  I haven't figured it out
yet, but some things in the comparator/tracker behavior look fishy.

Along the way, I made dwarfcmp print more details about reference
mismatches in attribute values (some explanation about in what way the
two referents don't match).  I also added -l, analogous to its cmp -l
counterpart, it shows all the mismatches rather than just the first.
Now "dwarfcmp -lT src/dwarflint{,}" shows all the reference mismatches
that should not be happening.

The case of the dwarfcmp binary itself is failing in dwarf_output
construction.  I don't understand it, but have not investigated very
thoroughly yet.  It's some failure of my logic for handling the hairy
reference cases.

As part of fixing the construction, I changed the internals of
dwarf_output::debug_info_entry::children_type as I'd been contemplating
for a while.  Now it has an "info ()" method that returns its underlying
type, a std::vector<die_info_pair *>.  That's still the pointer into the
collector's set of unique debug_info_entry objects, but now that's a map
so you get a pair<const debug_info_entry, die_info>.  die_info is where
we can hang any writer data structures, pointers to abbrev info, etc.
So when the writer does a tree walk, it can use children ().info () to
have the die_info pointer handy for each DIE it's emitting.  Its
_m_with_sibling and _m_uses fields are not really used for anything.
The stuff in the die_info will change more when we do the logic for
choosing what sharing to do.

My plan now is to keep working on the dwarfcmp -T dwarflint{,} case.
My best guess now is that this will just uncover bugs in the tracker
and/or comparator, and not have any bearing on the dwarfcmp case.  If
that's so, my next task will be fixing the construction bug in that
case.  After I get both of these fixed I will attack the matching of
duplicates involving circular refs.


Thanks,
Roland