public inbox for dwz@sourceware.org
 help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: dwz@sourceware.org
Subject: [Bug default/25449] New: Factor out compilation units
Date: Wed, 01 Jan 2020 00:00:00 -0000	[thread overview]
Message-ID: <bug-25449-11298@http.sourceware.org/bugzilla/> (raw)

https://sourceware.org/bugzilla/show_bug.cgi?id=25449

            Bug ID: 25449
           Summary: Factor out compilation units
           Product: dwz
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: default
          Assignee: nobody at sourceware dot org
          Reporter: vries at gcc dot gnu.org
                CC: dwz at sourceware dot org
  Target Milestone: ---

The dwarf standard contains "Appendix E -- DWARF Compression and Duplicate
Elimination (informative)", describing a technique on how to generate smaller
debug information:
...
to break up the debug information of a compilation into separate normal and
partial compilation units, each consisting of one or more sections. By
arranging that a sufficiently similar partitioning occurs in other
compilations, a suitable system linker can delete redundant groups of sections
when combining object files.
...

DWZ implements this scheme, but with the approach (described in pre-link terms
in the appendix) applied post-link.

It does this by:
- moving common DIEs into partial units (tagged with DW_TAG_partial_unit),
- generating DW_TAG_imported_unit/DW_AT_import to import the partial units
  into the compilation units which originally contained the DIEs
- referencing DIEs in partial units using DW_FORM_ref_addr, when referenced
from
  the originally containing compilation units or other partial units.

The appendix has a bit though on "Use of DW_TAG_compile_unit versus
DW_TAG_partial_unit":
...
A section group compilation unit that uses DW_TAG_compile_unit is like any
other compilation unit, in that its contents are evaluated by consumers as
though it were an ordinary compilation unit.

An #include directive appearing outside any other declarations is a good
candidate to be represented using DW_TAG_compile_unit.

However, an #include appearing inside a C++ namespace declaration or a
function, for example, is not a good candidate because the entities included
are not necessarily file level entities.

<SNIP>

Consequently a compiler must use DW_TAG_partial_unit (instead of
DW_TAG_compile_unit) in a section group whenever the section group contents are
not necessarily globally visible.

This directs consumers to ignore that compilation unit when scanning top level
declarations and definitions.

The DW_TAG_partial_unit compilation unit will be referenced from elsewhere and
the referencing locations give the appropriate context for interpreting the
partial compilation unit.
...

So, there also is an option to tag the created units with DW_TAG_compile_unit
instead of DW_TAG_partial_unit, which means no requirement to create
DW_TAG_imported_unit/DW_AT_import for such units, which means better
compression.

The first C++ example in the appendix shows this situation, and states:
...
This example uses DW_TAG_compile_unit for the section group, implying that the
contents of the compilation unit are globally visible (in accordance with C++
language rules). DW_TAG_partial_unit is not needed for the same reason.
...

So, as a first step we could do a optimization in DWZ to look at all the items
that are selected to be moved into a PU, and decide whether we can transform
the PU into a CU and drop the imports.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

             reply	other threads:[~2020-01-23  9:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-01  0:00 vries at gcc dot gnu.org [this message]
2020-01-01  0:00 ` [Bug default/25449] " vries at gcc dot gnu.org
2020-01-01  0:00 ` vries at gcc dot gnu.org
2020-01-01  0:00 ` vries at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-25449-11298@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=dwz@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).