Re: Two observations using GDB 13 snapshot

Luis Machado via Gdb-patches
2022-12-19T14:09:21Z

On 12/19/22 12:48, Eli Zaretskii wrote:
>> Date: Mon, 19 Dec 2022 10:07:27 +0000
>> From: Luis Machado <luis.machado@arm.com>
>>
>> On 12/17/22 17:42, Eli Zaretskii via Gdb-patches wrote:
>>> Using the latest snapshot of GDB 13 (MinGW build on native Windows), I
>>> see some strange behavior I've not seen with previous versions:
>>>
>>> . Very long time to read symbols. E.g., reading symbols of its own
>>> binary takes a whopping 2 minutes. GDB 12.1 does the same in
>>> under 10 seconds.
>>
>> There used to be a dwarf performance regression, but from looking at the bug (https://sourceware.org/bugzilla/show_bug.cgi?id=29105), it seems to be fixed.
>>
>> I'm not sure if it manifests differently on MinGW.
>
> 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.