From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DBBEC385801E; Mon, 24 Oct 2022 16:51:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DBBEC385801E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666630261; bh=KhG3LueqkuAQZDYNs3YZQ1uTg0v8Lp66zEndc0skzv4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=c6O0jZZ2+e8DMhjUPvrDxrXcZF4EBB8TEzynq8Vh5CX28Bu713SC7xgu8ySvfeGgv m/H84STsznqOGHjAs6XugdKpUsuU5UcoNuFy/bjTgbqXlytCZ7ynfqQdfMOJxSFVkz AyLZA7rj03dxj2FXS2EFr+whoWLNK2nUGhROQw60= From: "nickpelling at nickpelling dot com" 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: Mon, 24 Oct 2022 16:50:00 +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: nickpelling at nickpelling dot com 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: 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 --- Comment #3 from Nick Pelling --- Thanks very much Tom & Simon, I now have some additional debug info to shar= e. I tried using "maint set dwarf max-cache-age 0" but this made no noticeable difference (alas). I also tried "maintenance expand-symtabs", along with "s= et debug symfile on" and "set debug symbol-lookup 10", but these yielded no ex= tra information. I did get some more information using "set debug symtab-create", e.g. set debug symtab-create 10 set debug dwarf-read 10 set debug dwarf-line 10 This showed that the unexpected long pause for a given thread is happening after the final "Created symtab" message and before "Done expanding CU at offset": 794,918 &"Created symtab 0x213880c8 for module C:\\[File Path]\\repos\\platformmaster\\FreeRTOSLib\\lwip\\src\\include/lwip/prot/udp= .h.\n" 794,918 &"Created symtab 0x213880e8 for module ../../FreeRTOSLib/libcoap/include/coap2/utlist.h.\n" 800,521 &"Done expanding CU at offset 0x14dffb\n" The final printf here is in process_queues(), so the code seems to be inside process_full_comp_unit(), i.e. processing the CU's sequence of dwarf tokens. Similarly, it looks as though the code is exiting dwarf_decode_lines() befo= re the slowdown is happening: which seems to be right at the end of the code parsing the DW_AT_stmt_list token. Using "set debug dwarf-die 10" causes the dwarf tokens in the die to be pri= nted out (a little further up the gdb trace). The final two dwarf tokens in each= of the modules appear to be (for example): 772,637 &" DW_AT_stmt_list (DW_FORM_sec_offset) section offset: 206677\n" 772,637 &" DW_AT_GNU_macros (DW_FORM_sec_offset) section offset: 289465\= n" Hence I'm now wondering if there might actually be something malformed in t= he data being emitted by gcc following the DW_AT_GNU_macros dwarf token that is causing the dwarf_decode_macros() code to get subtly borked or confused. Unfortunately, there doesn't seem to be (unless I'm missing something obvio= us) a single line of debug trace in all the gdb macro-processing code, so I'm n= ot getting a lot of trace assistance from that. :-( Are there any known issues to do with gcc and parsing the DW_AT_GNU_macros token section that might be triggering an issue here? --=20 You are receiving this mail because: You are on the CC list for the bug.=