From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 56EE73857C4D; Fri, 17 Jun 2022 19:06:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 56EE73857C4D From: "jsm28 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: Fri, 17 Jun 2022 19:06:21 +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: jsm28 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: Fri, 17 Jun 2022 19:06:22 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23710 Joseph Myers changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsm28 at gcc dot gnu.org --- Comment #24 from Joseph Myers --- I've observed a case of GDB slowness on LTO code, still present with current GDB (testing here with GDB as of commit 2d9cf99d9a6c701de912d3e95ea3ffa134af4c62), that looks a bit different from = the cases discussed here. The customer test case has about 10 MB of text and about 1 GB of debug info= in the main C++ application (there are also lots of shared libraries involved)= .=20 Using GDB to examine a core dump (with about 300 threads), either "info threads" or "thread apply all bt" is both very slow on a binary built with = LTO (maybe 10 times slower than on a non-LTO binary) and consumes much more mem= ory. For the LTO binary and core dump, GDB loads the debug info for many more compilation units than in the non-LTO case, resulting in many more DIEs bei= ng loaded, process_die being called many more times (a factor of about 10) and much more time being spent in it (a large proportion of execution time in t= he LTO case is spent in process_die and its children). The key difference in the debug info in the LTO and non-LTO cases that caus= es this is references from the debug info for one CU to the debug info for ano= ther CU, as handled by follow_die_offset. In the non-LTO case these don't occur = at all. In the LTO case, there are many such references - the greatest proport= ion are DW_TAG_subprogram, but also various others such as DW_TAG_namespace and DW_TAG_variable. The key call is in follow_die_offset: /* If necessary, add it to the queue and load its DIEs. Even if maybe_queue_comp_unit doesn't require us to load the CU's DIEs, it doesn't mean they are currently loaded. Since we require them to be loaded, we must check for ourselves. */ if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->per_cu->lang) || per_objfile->get_cu (per_cu) =3D=3D nullptr) load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_= cu), false, cu->per_cu->lang); This call to load_full_comp_unit gets executed 9960 times in the LTO case, = but not at all in the non-LTO case. The other call to load_full_comp_unit that = gets executed is the one from load_cu (201 times in the non-LTO case, 150 in the= LTO case). So the DIEs from many more CUs are loaded in the LTO case. Then process_full_comp_unit calls process_die 2250 times in the LTO case but only 186 times in the non-LTO case (and that recurses down to process all the DI= Es in the CU). The underlying issue here looks like GDB's strategy of loading all the DIEs from any CU referenced by the debug info from a CU it's loading debug info from, rather than somehow e.g. only selectively loading the DIEs it needs f= or the particular backtrace being printed. --=20 You are receiving this mail because: You are on the CC list for the bug.=