Re: dwarf_output overview

[Mark Wielaard <mjw at redhat dot com>]

On Fri, 2010-08-06 at 15:21 -0700, Roland McGrath wrote:
> So the way I've formulated it is with these definitions:
> 
> * trees are equal if their tags, attributes, and children lists are equal
> * tags are integers, equality is integer equality
> * children lists are equal if the same length and respective child trees equal
> * attributes are equal if the same name/value pairs and equal values
> * non-reference attribute values are "simple" types, equality is
>   type-appropriate.  (Later, it may have strict/non-strict variants of
>   equality, for things like an exprloc vs a constant for
>   data_member_location location.  The point being there are more details
>   here in practice, but there is no more algorithmic complexity to be
>   thinking about now.)
> * reference attribute values are equal if their referent DIEs are equal
>   trees in equal-enough contexts
> * what goes into "context" and "equal-enough" is fungible and intended to
>   be tuned by practical experience with real data later in the project.
>   To begin with:
> * context of a DIE means its parent DIE's tag, non-reference attributes,
>   and context (hence iterate up to compile_unit level, which is not part of
>   the context).  (From prior discussions here, we will probably refine the
>   terminal context to include a small subset of compile_unit attributes.
>   For now, the simple definition stands.)
> 
> Hence, referent context is part of reference equality, but a tree's own
> context is not part of tree equality.

So from your earlier examples, and this definition, we know that having
two DIEs, A and B, that have an attribute X that refers to some other
DIE can only equal if the DIEs pointed to by A->X and B->X, lets call
them DIE Y and Z, are equal AND have equal[-enough] contexts.

But nothing prevents us from marking Y and Z itself equal. So, lets
assume they are, and we replace them with an imported_unit DIE. How do
we deal with A->X and B->X pointing to Y and Z? I assume they now point
to the imported_unit DIEs themselves so that any "logical" DIE tree will
still be the same.

But what if any other DIE might have an attribute pointing deeper into Y
or Z itself? Where would these attributes point to? If we make point
them somewhere into the partial_unit that replaced Y and Z then a
consumer doesn't know the context anymore.

Am I missing something, or is this a situation that cannot occur?

Thanks,

Mark