public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "nickpelling at nickpelling dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/29702] New: Huge slowdown just after loading thread DWARF data when hitting breakpoints (gdb in MCUXpresso / Eclipse) Date: Wed, 19 Oct 2022 15:15:52 +0000 [thread overview] Message-ID: <bug-29702-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=29702 Bug ID: 29702 Summary: Huge slowdown just after loading thread DWARF data when hitting breakpoints (gdb in MCUXpresso / Eclipse) Product: gdb Version: 10.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: nickpelling at nickpelling dot com Target Milestone: --- Hi everyone, As our (non-LTO, Debug) Cortex-M7 executable has got larger, so the length of time that MCUXpresso's gdb takes to hit the first breakpoint (near the end of main()) has steadily increased. 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). 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.) 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. From the trace, each thread causes gdb to parse the associated DIE, then parse the directories & files, and then process blocks of lines. After the final block of lines, there's a pause: though this pause is initially very short, it gets longer (up to 10 seconds) as more threads are loaded. For example, here's the gdb trace log for the last few lines of our ptpd thread startup code in startup_mcu.c: 359,753 &"Processing actual line 191: file 1, address 0x6006089e, is_stmt 1, discrim 0\n" 359,754 &"Recording line 191, file startup_mcu.c, address 0x6006089e\n" 359,754 &"Processing actual line 195: file 1, address 0x600608b8, is_stmt 1, discrim 0\n" 359,754 &"Recording line 195, file startup_mcu.c, address 0x600608b8\n" 359,754 &"Processing actual line 195: file 1, address 0x600608cc, is_stmt 1, discrim 0\t(end sequence)\n" 359,754 &"Finishing current line, file startup_mcu.c, address 0x600608cc\n" 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" These trace messages were triggered using: set debug dwarf-read 10 set debug dwarf-line 10 The C function this is describing is unremarkable (comments removed): 187: void ptpd_init(void) 188: { 189: bool bMaster; 190: bMaster = HOSTPLATFORM_TimeSync_ShouldBePTPMaster(); 191: xTaskCreate(ptpd_thread, "ptpd_task", PTPD_STACKSIZE_BYTES / 4, (void *)bMaster, PTPD_PRIORITY, &xCreatedTask); 192: 193: // Comment 194: // Comment 195:} 196: (end of file) 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. Any ideas what could be causing this super-annoying slowdown? I believe that "Recording line 0..." is in dwarf_decode_lines() --> dwarf_decode_lines_1() --> lnp_state_machine::record_line --> dwarf_finish_line() --> dwarf_record_line_1(). 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 and "Done expanding CU at offset..."? -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2022-10-19 15:16 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-19 15:15 nickpelling at nickpelling dot com [this message] 2022-10-21 16:53 ` [Bug gdb/29702] " tromey at sourceware dot org 2022-10-21 17:12 ` simark at simark dot ca 2022-10-24 16:50 ` nickpelling at nickpelling dot com 2022-10-24 17:07 ` simon.marchi at polymtl dot ca 2022-10-25 15:27 ` nickpelling at nickpelling dot com 2022-10-25 16:16 ` tromey at sourceware dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-29702-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).