From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5A7A53886C4F; Tue, 11 May 2021 08:15:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5A7A53886C4F From: "rguenth at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug macros/27754] Excessive CPU load and memory usage with -g3 debug info Date: Tue, 11 May 2021 08:15:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: macros X-Bugzilla-Version: 10.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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: cc 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, 11 May 2021 08:15:07 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27754 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at redhat dot com --- Comment #11 from Richard Biener --- (In reply to Tom Tromey from comment #9) > (In reply to Richard Biener from comment #6) > > The non-LTO .debug_macro has > >=20 > > DW_MACRO_import - offset : 0x0 > > DW_MACRO_end_file > >=20 > > as well, whatever that means. >=20 > The problem with LTO is that the output is pathological. > For example I see this sequence: >=20 > DW_MACRO_import - offset : 0x0 > DW_MACRO_end_file > DW_MACRO_import - offset : 0x0 > DW_MACRO_end_file > DW_MACRO_import - offset : 0x0 > DW_MACRO_end_file >=20 > This says to import the macros from offset 0 three times in succession. > While this is technically ok, it's also absurd. Is this really > intentional? This file imports the unit at offset 0x0 multiple times > -- 108 in fact. It does look odd. It appears that it might be a bug with relocation handling - the imports should be resolved from .rel[a].debug_macro. I notice the imports at offset zero all appear at the "end" of .debug_macro. The first CU with offset zero imports is Offset: 0x11f01 Version: 4 Offset size: 4 Offset into .debug_line: 0xc814 Referred from <0><10d76>: Abbrev Number: 1 (DW_TAG_compile_unit) <10d77> DW_AT_producer : (indirect string, offset: 0x5ea6c): GNU C= ++17=20 10.3.0 -mcpu=3Dcortex-m3 -mthumb -mfloat-abi=3Dsoft -march=3Darmv7-m -g3 -O3 -std=3Dgnu+ +17 -flto -fno-fat-lto-objects -ffunction-sections -fdata-sections --param=3Dmax-i nline-insns-single=3D500 <10d7b> DW_AT_language : 4 (C++) <10d7c> DW_AT_name : (indirect string, offset: 0x5f012): /home/rdie z/rdiez/arduino/JtagDue/Project/BareMetalSupport/Miscellaneous.cpp <10d80> DW_AT_comp_dir : (indirect string, offset: 0x80ec4): /home/rdie z/rdiez/arduino/JtagDue/BuildOutput/JtagDue-obj-release <10d84> DW_AT_stmt_list : 0xc814 <10d88> DW_AT_GNU_macros : 0x11f01 The exact same zero offset macro imports happen in the Debug non-LTO firmware btw. (as said, .debug_macro is generate at compile, not at link time). That said, a smaller example to reproduce those repeated offset zero imports would be nice to have. Unfortunately "preprocessed source" won't do it ... It might be that GCC simply misses something here. > We can probably work around it in gdb somehow. My first thought is > to have it simply skip multiple imports of the same unit. This could > in theory yield the wrong answer sometimes, though. >=20 > Looks vaguely related to bug#26303, in the "suspicious import" sense. --=20 You are receiving this mail because: You are on the CC list for the bug.=