This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: comparing die trees/graphs


> BTW. I do think it is good to be explicit about the classes of
> equivalence we can/want/do detect. It is sometimes very easy for us
> humans to say "look semantically equivalent", while the (syntactical)
> comparisons needed to proof such equivalence are pretty involved. And it
> would allow us to more easily experiment with turning some of them off.
> Like we have for context equivalence (equal-enough).

Agreed.  I guess I thought it was all fairly explicit, once I'd mentioned
about the equal-enough predicate for context DIE attributes.

> I was just thinking about how/when detecting what kinds of equivalence
> is the most opportune. My thinking was that some comparisons are
> easier/cheaper done when we are already doing some transformation on
> (reading in/writing out) the whole DIE tree already.

Oh, sure.  That is, some of the things dwarf_output is doing might be
things a pure comparator should do to be efficient.  Yeah, perhaps.  I
mean, it's certainly true that a goal of dwarf_output is that subtrees
that should be equivalent to dwarfcmp have equal .identity ()
(i.e. pointer equality) when you get them constructed in the
dwarf_output object.  So one way to do "pure" comparison is to just do
that and throw away the collected output objects rather than write
anything.  But part of the point of dwarfcmp is to be a least partly
independent implementation of the pure correct semantic comparison logic
so that it serves usefully as a validating test on what dwarf_output does.


Thanks,
Roland

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]