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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
