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. Once we have the whole system working well for correctly detecting the exact equality of trees, then we can later start in on the "equal enough" sorts of rules for when order doesn't really matter and so forth.
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. The dwarf_comparator is wrong, and it's apparently its circularity-related logic that is misleading it. So that needs to be fixed not to yield this false-positive. 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> or something like that. (In fact, we'll eventually get smart enough to have a single imported_unit pull in a sequence of two or more DIEs. But worry about that later.) Thanks, Roland _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
