From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B47813AABCB4; Tue, 17 Mar 2020 07:56:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B47813AABCB4 From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC Date: Tue, 17 Mar 2020 07:56:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 8.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned 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-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 07:56:45 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23710 --- Comment #13 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Tom de Vries : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D589902954da0= d1dd140b33e578954746c9bfc374 commit 589902954da0d1dd140b33e578954746c9bfc374 Author: Tom de Vries Date: Tue Mar 17 08:56:36 2020 +0100 [gdb] Skip imports of c++ CUs The DWARF standard appendix E.1 describes techniques that can be used f= or compression and deduplication: DIEs can be factored out into a new compilation unit, and referenced using DW_FORM_ref_addr. Such a new compilation unit can either use a DW_TAG_compile_unit or DW_TAG_partial_unit. If a DW_TAG_compile_unit is used, its contents is evaluated by consumers as though it were an ordinary compilation unit. = If a DW_TAG_partial_unit is used, it's only considered by consumers in the context of a DW_TAG_imported_unit. An example of when DW_TAG_partial_unit is required is when the factored= out DIEs are not top-level, f.i. because they were children of a namespace.= In such a case the corresponding DW_TAG_imported_unit will occur as child = of the namespace. In the case of factoring out DIEs from c++ compilation units, we can fa= ctor out into a new DW_TAG_compile_unit, and no DW_TAG_imported_unit is required. This begs the question how to interpret a top-level DW_TAG_imported_uni= t of a c++ DW_TAG_compile_unit compilation unit. The semantics of DW_TAG_imported_unit describe that the imported unit logically appears = at the point of the DW_TAG_imported_unit entry. But it's not clear what the effect should be in this case, since all the imported DIEs are already globally visible anyway, due to the use of DW_TAG_compile_unit. So, skip top-level imports of c++ DW_TAG_compile_unit compilation units= in process_imported_unit_die. Using the cc1 binary from PR23710 comment 1 and setting a breakpoint on do_rpo_vn: ... $ gdb \ -batch \ -iex "maint set dwarf max-cache-age 316" \ -iex "set language c++" \ -ex "b do_rpo_vn" \ cc1 ... we get a 8.1% reduction in execution time, due to reducing the number of partial symtabs expanded into full symtabs from 212 to 175. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-03-17 Tom de Vries PR gdb/23710 * dwarf2/read.h (struct dwarf2_per_cu_data): Add unit_type and = lang fields. * dwarf2/read.c (process_psymtab_comp_unit): Initialize unit_ty= pe and lang fields. (process_imported_unit_die): Skip import of c++ CUs. --=20 You are receiving this mail because: You are on the CC list for the bug.=