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

["tromey at sourceware dot org" <sourceware-bugzilla@sourceware.org>]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
(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):
> 
[...]
> 
> 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?

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 constructs
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 help.
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 and
> "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 that
can be fixed (like if there's N^2 behavior somewhere or the like)?

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