On Mon, 2011-02-14 at 17:26 -0800, Roland McGrath wrote:
> So I am now looking at only calculating the local hash when we
> finalize, but don't put the items directly in the cache, but only after
> we scanned over the whole CU. That way when we do put the item in the
> cache, we can calculate the full hash because we can be sure that all
> dies that the reference attributes (recursively) points at have their
> local hash set.
I can't tell whether that sounds like exactly what I always thought the
plan of the new algorithm was, or sounds like you're still not changing the
old way of doing things enough.
I am probably not changing enough, trying to not disturb the current
setup too much.
"When we currently finalize" is based on all the dismal
that we ought to be getting rid of.
yeah, I am probably just bad at splitting out the necessary versus
dismal hairy parts.
In initial cut of the new plan,
nothing actually gets finalized until the whole CU is being finalized.
So, the reason that I didn't do that directly was because only when we
finalize, do we create a die_info, which is necessary to hold the local
hash for each input die we transform to an output die and put into the
On my branch I now delay finalization till the whole CU is done in
final_unit (). In defined_self () a die_info with the local hash is
created (at which point all children exist and have their local hash
set). Then when the entry gets finalized all referenced entries already
have a die_info with a local hash set which can be used in calculating
the final hash.
This works for the small examples in tests/dwarf_edit_output. The
attributes_type hash is now calculated using all the local hashes of the
referenced dies in the attributes.
For the bigger examples in the testsuite with dwarfcmp-test -T it will
fail with a logic_error since it dwarfcmp detects that the input and
dwarf_output aren't equal. Next up is looking into that (I believe most
of these self-tests with dwarfcmp did also fail before/on the dwarf