Re: Two observations using GDB 13 snapshot

Eli Zaretskii via Gdb-patches
2022-12-19T14:46:09Z

> Date: Mon, 19 Dec 2022 14:08:27 +0000
> Cc: gdb-patches@sourceware.org
> From: Luis Machado <luis.machado@arm.com>
>
> On 12/19/22 12:48, Eli Zaretskii wrote:
> > This build is without std::thread. Maybe it's related?
>
> Well, if the worker threads are disabled and things are read by a single thread, that may explain some slowness. But I don't think it would be as slow as you describe.
>
> >
> > Does GDB 13 read DWARF debug info significantly differently than
> > previous versions?
> >
> > Do you see this on GNU/Linux, when debugging GDB with itself, if you
> > disable multithreaded DWARF reading?
>
> For a regular build of GDB 13 (threaded), I see a pretty quick startup (about 3.5 seconds) to start gdb within gdb.
>
> With a GDB 13 built with threading disabled, I see about 15 seconds to do the same.
>
> Now, I noticed -readnow doesn't seem to use the worker threads for reading symbols, so passing that option slow things down significantly, to the point it takes 2 minutes to read the symbols.
>
> I don't know if that's on purpose.

Thanks.

Tom, could you please chime in? What could explain such a slowdown
using -readnow and in the MinGW build without worker threads (since
GDB 12 didn't use threads, either)? And why -readnow is so different
from a GDB built without threading?