Re: dwarf_edit_output testcase sanity checking

[Mark Wielaard <mjw at redhat dot com>]

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