DW_TAG_imported_unit

[Roland McGrath <roland at redhat dot com>]

So, to elaborate a bit on "semantic compression", the key means there is
DW_TAG_imported_unit.  

The long comment at the top of c++/dwarf talks about the "logical" vs "raw"
view of the DIE tree.  The trivial parts of that are hiding DW_AT_sibling
and DW_TAG_partial_unit from view.  The significant part is that the
logical view expands any DW_TAG_imported_unit children in the raw DIE tree
so that the logical view never includes a DW_TAG_imported_unit DIE.
Instead, where the raw view sees a DW_TAG_imported_unit, the logical view
insteads sees one or more different DIEs there (the children of the
other CU referenced by DW_TAG_imported_unit's DW_AT_import).

The output-side C++ interfaces have no "raw view" at all.  Instead, the
only presentation in dwarf_edit and dwarf_output maps to the "logical view"
from the dwarf reader class.  The automatic de-duplication code in the
writer will work by identifying identical DIE subtrees used more than once,
and replacing them with DW_TAG_imported_unit pointers when composing the
output CUs.

This is why dwarfcmp compares the logical view.  The de-duplicating
transformation using DW_TAG_imported_unit is a no-op in the abstract, and
should not change anything about the logical view.

The very first crack at writing will not generate DW_TAG_imported_unit.
But the basic design of the collector is all organized around consolidating
duplication on the way in so we have only one copy stored in the collector.
For the "dumb" writer mode, we will then produce identical duplicates from
the shared data structures.  But the stage will be set for "smart" mode.


Thanks,
Roland