From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E7B75385417B; Fri, 21 Oct 2022 16:53:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E7B75385417B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666371233; bh=HMzXRilf/SHc0h0js/zPnK446oi1836PA5gHUsH5OFc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=i5VRbV2PgAiPeQANWCZ9Vg5PeusvG7zzj0JwDe9+mTzQ0jflC+zNRKG4331FzLBYo jUN9L0oS+WI66pI/sLj1YMpD2Riuq3iKcOOqsutULmddWXQKMV9a5irPMIGYeSRqPm 4nJvURsYCCwbyMoyUV4GVXXGA1ffi5jkZaYeUleA= From: "tromey at sourceware dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/29702] Huge slowdown just after loading thread DWARF data when hitting breakpoints (gdb in MCUXpresso / Eclipse) Date: Fri, 21 Oct 2022 16:53:53 +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: 10.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tromey at sourceware dot org X-Bugzilla-Status: UNCONFIRMED 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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29702 Tom Tromey changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tromey at sourceware dot o= rg --- Comment #1 from Tom Tromey --- (In reply to Nick Pelling from comment #0) > I first noticed this with GNU gdb (GNU Tools for Arm Embedded Processors > 8-2019-q3-update) 8.3.0.20190703-git, but hoped it would go away when we > upgraded to GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) > 10.2.90.20210621-git (though this too suffered from the same issue, alas). Might be worth trying an even newer version. > With 16 threads, I'm seeing a 30-second delay. And with 25 threads, I'm > seeing a 60-second delay. (Note: the breakpoint is after the threads have > been first created, but before the FreeRTOS scheduler has actually called > any of them.) It seems strange to me that the number of threads has an impact like this. > By enabling loads of gdb trace debug flags, I believe I have isolated the > slowdown to the gdb code just after it has parsed the DWARF data for each > thread/task. > For example, here's the gdb trace log for the last few lines of our ptpd > thread startup code in startup_mcu.c: This doesn't show the timestamp / output for the "Expanding one or more symtabs" message that I'd expect to see. > 359,754 &"Recording line 0, file startup_mcu.c, address 0x600608cc\n" > 369,835 &"Done expanding CU at offset 0x556b6\n" > 369,835 &"Done expanding symtabs of C:\\[File > Path]\\Platform_FreeRTOS.axf.\n" > The C function this is describing is unremarkable (comments removed): >=20 [...] >=20 > And yet looking at the timestamps, you can see a whopping 10-second gap > between the final "Recording line 0, file startup_mcu.c,..." line and the > immediately following "Done expanding CU at offset 0x556b6\n" line. >=20 > Any ideas what could be causing this super-annoying slowdown? gdb's DWARF reader has two phases. In the first phase it reads "partial symbols" (this step is reimplemented for GDB 13 and the names are all different, but= the idea is the same). When gdb needs full information about some object, e.g. when you set a breakpoint or when it attaches and tries to find out where the current PC is located, = then it will expand these partial symbols to full symbols. To do this, it reads the DWARF for the entire compilation unit and construc= ts symbols for everything there. It's possible that if your compilation units are very large, then this will= be slow. We'd like to fix this (see bug #29398) but it is not easy. If your DWARF has intra-CU references then bumping the max cache age can he= lp. See bug #25703. This may only affect LTO and/or dwz though. The last time I saw a very bad slowdown was with -g3 and it turned out to be a bad interaction between GCC and mold. I don't know if that could be your situation. > Also: are there any additional gdb trace flags I can enable to get more > information about what it's doing between the end of the dwarf decoding a= nd > "Done expanding CU at offset..."? Not really, I think. Though of course you can always add instrumentation, or run it under a profiler. It would be interesting to learn more about your situation. For example if= it is a pathological CU expansion of some kind, is there a bug in the reader t= hat can be fixed (like if there's N^2 behavior somewhere or the like)? --=20 You are receiving this mail because: You are on the CC list for the bug.=