On Thu, 2010-10-21 at 23:14 -0400, Roland McGrath wrote:
As you say, order does matter sometimes. So the intent is that
we'll start
out with only calling two trees equal if they are exactly equal, ordering
included. Hence, I'd say that dwarf_comparator is broken to call those two
CUs equal right now.
It doesn't say the CUs are equal (I will add an extra test to make
sure), but the var DIEs are. Now that I slept on it, and reading the
rest of your email, I think that is correct (so it is the dwarf_output
copier that is broken and that should also detect the var DIEs as
equal).
Note that in this case, I think the two structure_type subtrees
should
indeed be equal. The reference chain is important to the equality, but the
pointer_type's ordering within the CU does not affect that.
So, here each child of the compile_unit should be found identical to a
corresponding child in the other compile_unit. But the two compile_unit
full trees are indeed not equal.
Right. So order matters for DIE children, but not for referenced DIEs in
attributes.
i.e. in the compressed output we'd get:
<compile_unit producer="dwarf_edit_output_test">
<imported_unit import="ref8"/> # the base_type
<imported_unit import="ref9"/> # the pointer_type
<imported_unit import="ref7"/> # the structure_type
<imported_unit import="ref22"/> # the variable
</compile_unit>
<compile_unit producer="dwarf_edit_output_test">
<imported_unit import="ref8"/> # the base_type
<imported_unit import="ref7"/> # the structure_type
<imported_unit import="ref9"/> # the pointer_type
<imported_unit import="ref22"/> # the variable
</compile_unit>
And thanks for the example compressed output. It all makes sense now.
I am off now trying to figure out why the dwarf_output copier doesn't
mark each individual child DIE equal between the two CUs. It does for
the (IMHO trickier) testcase 11.
Cheers,
Mark