From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78322 invoked by alias); 23 Jan 2020 11:49:27 -0000 Mailing-List: contact dwz-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: dwz-owner@sourceware.org Received: (qmail 78291 invoked by uid 48); 23 Jan 2020 11:49:23 -0000 From: "vries at gcc dot gnu.org" To: dwz@sourceware.org Subject: [Bug default/25449] Factor out compilation units Date: Wed, 01 Jan 2020 00:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: dwz X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: nobody at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2020-q1/txt/msg00040.txt https://sourceware.org/bugzilla/show_bug.cgi?id=3D25449 --- Comment #2 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > 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 bit of "no requirement to create DW_TAG_imported_unit/DW_AT_import for = such units" is not entirely trivial. In appendix E we find: ... Use of DW_TAG_imported_unit A DW_TAG_imported_unit debugging information entry has an DW_AT_import attribute referencing a DW_TAG_compile_unit or DW_TAG_partial_unit debugging information entry. A DW_TAG_imported_unit debugging information entry refers to a DW_TAG_compile_unit or DW_TAG_partial_unit debugging information entry to specify that the DW_TAG_compile_unit or DW_TAG_partial_unit contents logica= lly appear at the point of the DW_TAG_imported_unit entry. ... So, it's possible to do an import of a compile unit. But in the first C++ example in E.1, the import statement for the compilati= on unit is missing, while in the first Fortran example in E1, the import state= ment for the partial unit is included. Furthermore, at 3.1.1 Normal and Partial Compilation Unit Entries, we have: ... A compilation unit entry owns debugging information entries that represent = all or part of the declarations made in the corresponding compilation. In the c= ase of a partial compilation unit, the containing scope of its owned declaratio= ns is indicated by imported unit entries in one or more other compilation unit entries that refer to that partial compilation unit. ... A bit of explanation about when import is used and when not occurs here in = E.1 "C example": ... The C++ example in this Section might appear to be equally valid as a C example. However, it is prudent to include a DW_TAG_imported_unit in the primary unit (see Figure 84) with an DW_AT_import attribute that refers to = the proper unit in the section group. The C rules for consistency of global (file scope) symbols across compilati= ons are less strict than for C++; inclusion of the import unit attribute assures that the declarations of the proper section group are considered before declarations from other compilations. ... So, the jist of this seems to be: - factored out partial unit: needs import - factored out compilation unit: - prudent to import from C compilation unit (but we can have f.i. a command line option to not do this, and see what breaks) - not required from C++ compilation unit --=20 You are receiving this mail because: You are on the CC list for the bug.