[Bug gdb/29702] Huge slowdown just after loading thread DWARF data when hitting breakpoints (gdb in MCUXpresso / Eclipse)

["simon.marchi at polymtl dot ca" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29702

Simon Marchi <simon.marchi at polymtl dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.marchi at polymtl dot ca

--- Comment #4 from Simon Marchi <simon.marchi at polymtl dot ca> ---
(In reply to Nick Pelling from comment #3)
> Thanks very much Tom & Simon, I now have some additional debug info to share.
> 
> 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
> "set debug symfile on" and "set debug symbol-lookup 10", but these yielded
> no extra 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()
> before 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
> printed 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
> the 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
> obvious) a single line of debug trace in all the gdb macro-processing code,
> so I'm not 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?

Maybe this: https://sourceware.org/bugzilla/show_bug.cgi?id=27754

This is what Tom was referring to when he said:

> 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.

Basically, bad interaction between gcc and the linker would cause the macro
information to have a bunch of `DW_MACRO_import` with offset 0, when they were
actually supposed to reference some other offset.

You can check your file with `readelf --debug-dump=macro`, go to offset 0x46ab9
(I got this from your logs, it's 289465 decimal).  If there are a bunch of
`DW_MACRO_import 0x0`, it's likely this problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.