Two observations using GDB 13 snapshot

Two observations using GDB 13 snapshot

[Eli Zaretskii]

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.

  . The (top-gdb) prompt doesn't appear when debugging GDB with
    itself.

Are these bugs or features?

Re: Two observations using GDB 13 snapshot

[Luis Machado]

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.

> 
>    . The (top-gdb) prompt doesn't appear when debugging GDB with
>      itself.
> 
> Are these bugs or features?

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

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

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?

Thanks.

Re: Two observations using GDB 13 snapshot

[Luis Machado]

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.

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

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

Re: Two observations using GDB 13 snapshot

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> writes:

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

Just a quick answer for now, I haven't tried to reproduce or
investigate...

-readnow should not really be affected by the DWARF scanner rewrite.
With -readnow, all the new code is bypassed anyway.  For quite a while
now, -readnow (when using DWARF anyway) has operated on the principle
that since gdb is reading full symbols, it might as well not bother with
partial symbols (or now, the index).

Threads also should not matter here, because only the initial scan can
use multiple threads.  The full symbol reader is single-threaded and
hasn't changed in any deep way since GDB 12.

It's possible that some other change affected this -- the DWARF reader
in general sees a lot of patches.  I don't know which one it might be
offhand, though.

Tom

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Luis Machado <luis.machado@arm.com>,  Tom Tromey <tom@tromey.com>,  Eli
>  Zaretskii <eliz@gnu.org>
> Date: Mon, 19 Dec 2022 14:18:52 -0700
> 
> >>>>> "Eli" == Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Eli> Tom, could you please chime in?  What could explain such a slowdown
> Eli> using -readnow and in the MinGW build without worker threads (since
> Eli> GDB 12 didn't use threads, either)?  And why -readnow is so different
> Eli> from a GDB built without threading?
> 
> Just a quick answer for now, I haven't tried to reproduce or
> investigate...
> 
> -readnow should not really be affected by the DWARF scanner rewrite.
> With -readnow, all the new code is bypassed anyway.  For quite a while
> now, -readnow (when using DWARF anyway) has operated on the principle
> that since gdb is reading full symbols, it might as well not bother with
> partial symbols (or now, the index).
> 
> Threads also should not matter here, because only the initial scan can
> use multiple threads.  The full symbol reader is single-threaded and
> hasn't changed in any deep way since GDB 12.
> 
> It's possible that some other change affected this -- the DWARF reader
> in general sees a lot of patches.  I don't know which one it might be
> offhand, though.

So you are saying that the rewrite of the DWARF scanner could be the
reason for the slowness?

Let me know if I can provide any additional information that could be
useful in investigating this.

Would it be useful to open a bugzilla issue?

Re: Two observations using GDB 13 snapshot

[Simon Marchi]

On 12/19/22 22:26, Eli Zaretskii via Gdb-patches wrote:
>> From: Tom Tromey <tom@tromey.com>
>> Cc: Luis Machado <luis.machado@arm.com>,  Tom Tromey <tom@tromey.com>,  Eli
>>  Zaretskii <eliz@gnu.org>
>> Date: Mon, 19 Dec 2022 14:18:52 -0700
>>
>>>>>>> "Eli" == Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> writes:
>>
>> Eli> Tom, could you please chime in?  What could explain such a slowdown
>> Eli> using -readnow and in the MinGW build without worker threads (since
>> Eli> GDB 12 didn't use threads, either)?  And why -readnow is so different
>> Eli> from a GDB built without threading?
>>
>> Just a quick answer for now, I haven't tried to reproduce or
>> investigate...
>>
>> -readnow should not really be affected by the DWARF scanner rewrite.
>> With -readnow, all the new code is bypassed anyway.  For quite a while
>> now, -readnow (when using DWARF anyway) has operated on the principle
>> that since gdb is reading full symbols, it might as well not bother with
>> partial symbols (or now, the index).
>>
>> Threads also should not matter here, because only the initial scan can
>> use multiple threads.  The full symbol reader is single-threaded and
>> hasn't changed in any deep way since GDB 12.
>>
>> It's possible that some other change affected this -- the DWARF reader
>> in general sees a lot of patches.  I don't know which one it might be
>> offhand, though.
> 
> So you are saying that the rewrite of the DWARF scanner could be the
> reason for the slowness?
> 
> Let me know if I can provide any additional information that could be
> useful in investigating this.

Just wondering, do you build with or without optimizations?

Simon

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> Date: Thu, 22 Dec 2022 22:34:01 -0500
> Cc: gdb-patches@sourceware.org, luis.machado@arm.com
> From: Simon Marchi <simark@simark.ca>
> 
> Just wondering, do you build with or without optimizations?

With.  The GCC switches in gdb/Makefile are:

  CFLAGS = -O2 -gdwarf-4 -g3
  CXXFLAGS = -O2 -gdwarf-4 -g3

Re: Two observations using GDB 13 snapshot

[Tom Tromey]

Eli> So you are saying that the rewrite of the DWARF scanner could be the
Eli> reason for the slowness?

No, sorry.

-readnow should not be affected much, if at all, by the rewrite.  The
new code is not used when -readnow is given.  There's a case in
dwarf2_initialize_objfile that ensures this.

-readnow is just generally much slower because it does a lot more work.
I don't know why it would have slowed down between 12 and 13, though.

Eli> Let me know if I can provide any additional information that could be
Eli> useful in investigating this.

Eli> Would it be useful to open a bugzilla issue?

The best thing would be some kind of comparison of profiles between the
two versions, to try to see what caused the slowdown.  However, that's a
lot of work.

FWIW I tend not to pay much attention to -readnow.  I never use it
myself and I try to dissuade others from using it as well.

Tom

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org,
>   luis.machado@arm.com
> Date: Sat, 24 Dec 2022 10:57:53 -0700
> 
> Eli> So you are saying that the rewrite of the DWARF scanner could be the
> Eli> reason for the slowness?
> 
> No, sorry.
> 
> -readnow should not be affected much, if at all, by the rewrite.  The
> new code is not used when -readnow is given.  There's a case in
> dwarf2_initialize_objfile that ensures this.
> 
> -readnow is just generally much slower because it does a lot more work.
> I don't know why it would have slowed down between 12 and 13, though.
> 
> Eli> Let me know if I can provide any additional information that could be
> Eli> useful in investigating this.
> 
> Eli> Would it be useful to open a bugzilla issue?
> 
> The best thing would be some kind of comparison of profiles between the
> two versions, to try to see what caused the slowdown.  However, that's a
> lot of work.
> 
> FWIW I tend not to pay much attention to -readnow.  I never use it
> myself and I try to dissuade others from using it as well.

 -readnow doesn't interest me (I never use it), except as some evidence
 or data point regarding the slow reading of debug info.

All I'm interested in is to help you and others understand what could
be the reason for slow reading of debug info at startup, so that it
could be sped up at some point.

Re: Two observations using GDB 13 snapshot

[Tom Tromey]

Eli> All I'm interested in is to help you and others understand what could
Eli> be the reason for slow reading of debug info at startup, so that it
Eli> could be sped up at some point.

Ok.  I re-read the thread and I see that at the beginning you didn't
mention -readnow.  So, assuming that the -readnow stuff was a
distraction...

The new indexer should not be significantly slower even when
single-threaded.  On my machine, if I "maint set worker-threads 0" and
then use a -O2 build of gdb, it's about as fast as the system /bin/gdb
(which uses the old code).

Old:

    (gdb) file ./gdb
    [...]
    Command execution time: 2.408843 (cpu), 2.130013 (wall)

New:

    (gdb) file ./gdb
    [...]
    Command execution time: 2.858222 (cpu), 2.865426 (wall)

This is only slightly worse.

Now there is a known bug in some linkers when -g3 is used, which causes
a pretty severe slowdown in gdb.  See:

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

I would have thought that this could not affect your build.  However I
don't know for certain.

Tom

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org,
>   luis.machado@arm.com
> Date: Tue, 27 Dec 2022 10:19:24 -0700
> 
> Eli> All I'm interested in is to help you and others understand what could
> Eli> be the reason for slow reading of debug info at startup, so that it
> Eli> could be sped up at some point.
> 
> Ok.  I re-read the thread and I see that at the beginning you didn't
> mention -readnow.  So, assuming that the -readnow stuff was a
> distraction...

Right.  When it was brought up, I thought -readnow was indicative of
what I see, but then you said it doesn't use the new DWARF reader
code, so it is not relevant.

> The new indexer should not be significantly slower even when
> single-threaded.  On my machine, if I "maint set worker-threads 0" and
> then use a -O2 build of gdb, it's about as fast as the system /bin/gdb
> (which uses the old code).
> 
> Old:
> 
>     (gdb) file ./gdb
>     [...]
>     Command execution time: 2.408843 (cpu), 2.130013 (wall)
> 
> New:
> 
>     (gdb) file ./gdb
>     [...]
>     Command execution time: 2.858222 (cpu), 2.865426 (wall)
> 
> This is only slightly worse.

My numbers are very different:

 . with GDB-12.1:                 elapsed: 8.39 sec,  CPU: 6.25 sec
 . with gdb-13.0.50.20221217-git: elapsed: 135.8 sec, CPU: 130.5 sec

No significant difference in memory consumption: 453MB for GDB 12.1,
441MB for GDB 13.

(Interestingly, when reading symbols from Emacs on the same system,
the times are almost identical: 2.593 for GDB 12 vs 2.671 for GDB 13.)

Other details which might be important:

  GCC 9.2.0
  Binutils 2.39
  GDB compilation switches: -O2 -gdwarf-4 -g3

And one more thing: this is a native 32-bit Windows build of GDB, so
it has DWARF2 info in PE-COFF file, not in ELF.  Maybe this could
explain the difference?  Or maybe the C++ code is a factor?

Thanks.

Re: Two observations using GDB 13 snapshot

[Luis Machado]

On 12/27/22 18:00, Eli Zaretskii wrote:
>> From: Tom Tromey <tom@tromey.com>
>> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org,
>>    luis.machado@arm.com
>> Date: Tue, 27 Dec 2022 10:19:24 -0700
>>
>> Eli> All I'm interested in is to help you and others understand what could
>> Eli> be the reason for slow reading of debug info at startup, so that it
>> Eli> could be sped up at some point.
>>
>> Ok.  I re-read the thread and I see that at the beginning you didn't
>> mention -readnow.  So, assuming that the -readnow stuff was a
>> distraction...
> 
> Right.  When it was brought up, I thought -readnow was indicative of
> what I see, but then you said it doesn't use the new DWARF reader
> code, so it is not relevant.

Sorry I brought -readnow up. I wasn't aware that mode didn't take advantage of the new DWARF reader. So it ended up
causing some confusion.

> 
>> The new indexer should not be significantly slower even when
>> single-threaded.  On my machine, if I "maint set worker-threads 0" and
>> then use a -O2 build of gdb, it's about as fast as the system /bin/gdb
>> (which uses the old code).
>>
>> Old:
>>
>>      (gdb) file ./gdb
>>      [...]
>>      Command execution time: 2.408843 (cpu), 2.130013 (wall)
>>
>> New:
>>
>>      (gdb) file ./gdb
>>      [...]
>>      Command execution time: 2.858222 (cpu), 2.865426 (wall)
>>
>> This is only slightly worse.
> 
> My numbers are very different:
> 
>   . with GDB-12.1:                 elapsed: 8.39 sec,  CPU: 6.25 sec
>   . with gdb-13.0.50.20221217-git: elapsed: 135.8 sec, CPU: 130.5 sec
> 
> No significant difference in memory consumption: 453MB for GDB 12.1,
> 441MB for GDB 13.
> 
> (Interestingly, when reading symbols from Emacs on the same system,
> the times are almost identical: 2.593 for GDB 12 vs 2.671 for GDB 13.)
> 
> Other details which might be important:
> 
>    GCC 9.2.0
>    Binutils 2.39
>    GDB compilation switches: -O2 -gdwarf-4 -g3
> 
> And one more thing: this is a native 32-bit Windows build of GDB, so
> it has DWARF2 info in PE-COFF file, not in ELF.  Maybe this could
> explain the difference?  Or maybe the C++ code is a factor?
> 
> Thanks.

Re: Two observations using GDB 13 snapshot

[Tom Tromey]

Eli> And one more thing: this is a native 32-bit Windows build of GDB, so
Eli> it has DWARF2 info in PE-COFF file, not in ELF.  Maybe this could
Eli> explain the difference?  Or maybe the C++ code is a factor?

The object file format shouldn't make a difference.  The DWARF code just
reads the appropriate sections (this code hasn't changed since GDB 12)
and the actual parsing is independent of the object file format.

C++ being used in the executable would possibly explain the difference
between reading GDB and reading Emacs, but I don't think it could
explain the performance difference between GDB 12 and 13 reading the
same executable.

I don't have a theory for what could be wrong.  Maybe profiling is the
best way.  It might also be interesting to verify that the
parallel_for_each in gdb/dwarf2/read.c is the culprit; that can be done
by setting breakpoints before and after it and measuring the time it
takes to "cont" from one to the other.  The idea of this is that if the
new reader is the source of the problem, it would show up here.

Tom

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org,
>   luis.machado@arm.com
> Date: Wed, 28 Dec 2022 09:35:33 -0700
> 
> I don't have a theory for what could be wrong.  Maybe profiling is the
> best way.

OK.  Should it be enough to just recompile in the gdb directory with

  make CXXFLAGS=-pg

or do I have to reconfigure with --enable-profiling?

Re: Two observations using GDB 13 snapshot

[Tom Tromey]

Eli> OK.  Should it be enough to just recompile in the gdb directory with

Eli>   make CXXFLAGS=-pg

Eli> or do I have to reconfigure with --enable-profiling?

I think rebuilding should be sufficient but it's been a long time since
I did this, so I'm not totally sure.

Tom

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org,
>   luis.machado@arm.com
> Date: Wed, 28 Dec 2022 15:47:09 -0700
> 
> Eli> OK.  Should it be enough to just recompile in the gdb directory with
> 
> Eli>   make CXXFLAGS=-pg
> 
> Eli> or do I have to reconfigure with --enable-profiling?
> 
> I think rebuilding should be sufficient but it's been a long time since
> I did this, so I'm not totally sure.

I've rebuilt with -pg in the following directories:

  . libiberty
  . bfd
  . opcodes
  . libctf
  . gdbsupport
  . gdb

The profile produced by gprof is attached.  The time information looks
very inaccurate, almost bogus, to me (since GDB ran for more than 2
minutes, I expected to see gdb_main show 130 as the value of
cumulative seconds, but the profile shows only 2.21?).  But
nevertheless I hope the data will be useful.

Let me know if I can provide more information.


[-- Attachment #2: gdb_read_symbols.prof.xz --]
[-- Type: application/octet-stream, Size: 88016 bytes --]

Re: Two observations using GDB 13 snapshot

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> The profile produced by gprof is attached.  The time information looks
Eli> very inaccurate, almost bogus, to me (since GDB ran for more than 2
Eli> minutes, I expected to see gdb_main show 130 as the value of
Eli> cumulative seconds, but the profile shows only 2.21?).

Yeah, it looks strange to me as well.  I don't think it really shows us
where all the time is going.

gprof also thinks gdb only ran for a couple of seconds:

> granularity: each sample hit covers 4 byte(s) for 0.44% of 2.29 seconds

I wonder if just randomly interrupting gdb a few times during that 2
minutes and doing a "bt" would be more informative.

Tom

Re: Two observations using GDB 13 snapshot

[John Baldwin]

On 12/29/22 10:17 AM, Tom Tromey wrote:
>>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> The profile produced by gprof is attached.  The time information looks
> Eli> very inaccurate, almost bogus, to me (since GDB ran for more than 2
> Eli> minutes, I expected to see gdb_main show 130 as the value of
> Eli> cumulative seconds, but the profile shows only 2.21?).
> 
> Yeah, it looks strange to me as well.  I don't think it really shows us
> where all the time is going.
> 
> gprof also thinks gdb only ran for a couple of seconds:
> 
>> granularity: each sample hit covers 4 byte(s) for 0.44% of 2.29 seconds
> 
> I wonder if just randomly interrupting gdb a few times during that 2
> minutes and doing a "bt" would be more informative.

It wouldn't surprise me if -pg is somewhat broken in modern toolchains
and supporting libraries.  Profiling nowadays is usually driven by
samping using hardware performance counters (like perf on Linux) rather
than relying on calls to instrumentation functions like mcount inserted
by the compiler.  I'm sure Windows has a way to use hardware performance
counters as well, but I'm not familiar with how to do it on Windows.

-- 
John Baldwin

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org,
>   luis.machado@arm.com
> Date: Thu, 29 Dec 2022 11:17:27 -0700
> 
> I wonder if just randomly interrupting gdb a few times during that 2
> minutes and doing a "bt" would be more informative.

Done, see the attached.


[-- Attachment #2: dwarf2-read-debug-session.txt --]
[-- Type: text/plain, Size: 108383 bytes --]

Thread 4 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1784.0x1074]
0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x004e78f0 in cpnameyylex (lvalp=lvalp@entry=0x1df1e468, state=0x1df1f918)
    at cp-name-parser.y:1930
1930    }
(gdb) bt
#0  0x004e78f0 in cpnameyylex (lvalp=lvalp@entry=0x1df1e468, state=0x1df1f918)
    at cp-name-parser.y:1930
#1  0x004e8e10 in cpnameyyparse (state=<optimized out>,
    state@entry=0x1df1f918) at cp-name-parser.c.tmp:1857
#2  0x004eb45a in cp_demangled_name_to_comp (
    demangled_name=demangled_name@entry=0x2a16a170 "new_allocator<std::unique_ptr<objfile, std::default_delete<objfile> > >", errmsg=errmsg@entry=0x0)
    at cp-name-parser.y:2044
#3  0x004f279c in cp_canonicalize_string (
    string=0x2a16a170 "new_allocator<std::unique_ptr<objfile, std::default_delete<objfile> > >") at cp-support.c:634
#4  0x005117ff in cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:224
#5  0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#6  std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#7  std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#8  gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#9  cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#10 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#11 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#12 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#13 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#14 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#15 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#16 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#17 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#18 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#19 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#20 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#21 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#22 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#23 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#24 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#25 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#26 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#27 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32
(gdb) c
Continuing.
[Thread 1784.0x1074 exited with code 0]
[New Thread 1784.0x14a0]

Thread 6 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1784.0x290]
0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x77c348d5 in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0  0x77c348d5 in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#1  0x77c348cd in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#2  0x77c30045 in wmktemp () from C:\WINDOWS\system32\msvcrt.dll
#3  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
#4  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#5  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#6  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150
#7  <lambda(const cooked_index_entry*, const cooked_index_entry*)>::operator()
    (__closure=<optimized out>, b=<optimized out>, a=<optimized out>)
    at dwarf2/cooked-index.c:249
#8  __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >::operator()<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> > > (this=<optimized out>, __it2=..., __it1=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/predefined_ops.h:143
#9  std::__unguarded_partition<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__pivot=..., __last=0xffffffff, __first=0x21f63390, __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1904
#10 std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__last=0x35e8e7f0, __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1922
#11 std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >)
    (__first=<error reading variable: Cannot access memory at address 0x1>,
    __first@entry=0x366c82b0, __last=__last@entry=0x35e8e7f0,
    __depth_limit=18, __depth_limit@entry=19, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1952
#12 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x39baaf30,
    __last=__last@entry=0x35e8e7f0, __depth_limit=19, __depth_limit@entry=20,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#13 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x35db1a70,
    __last=__last@entry=0x358fef30, __depth_limit=20, __depth_limit@entry=24,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#14 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x35f58dd0,
    __last=__last@entry=0x358fef30, __depth_limit=24, __depth_limit@entry=25,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#15 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x395c88d0,
    __last=__last@entry=0x21fbce10, __depth_limit=25, __depth_limit@entry=27,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#16 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x35d43150,
    __last=__last@entry=0x2233f390, __depth_limit=27, __depth_limit@entry=29,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#17 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x35c42f50,
    __last=__last@entry=0x378cc3b0, __depth_limit=29, __depth_limit@entry=31,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#18 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37207470,
    __last=__last@entry=0x38504390, __depth_limit=31, __depth_limit@entry=35,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#19 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x35f66a50, __last=__last@entry=0x0,
    __depth_limit=35, __depth_limit@entry=37, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#20 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x363df850, __last=__last@entry=0x0,
    __depth_limit=37, __depth_limit@entry=38, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#21 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37382a70, __last=__last@entry=0x0,
    __depth_limit=38, __depth_limit@entry=39, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#22 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3873cf10, __last=__last@entry=0x0,
    __depth_limit=39, __depth_limit@entry=40, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#23 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x2145fb08, __last=__last@entry=0x0,
    __depth_limit=40, __depth_limit@entry=41, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#24 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37e76f10, __last=__last@entry=0x0,
    __depth_limit=41, __depth_limit@entry=42, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#25 0x00511672 in std::__sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__comp=..., __last=..., __first=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1967
#26 std::sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > (__last=..., __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:4860
#27 cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:246
#28 0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#29 std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#30 std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#31 gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#32 cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#33 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#34 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#35 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#36 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#37 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#38 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#39 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#40 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#41 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#42 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#43 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#44 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#45 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#46 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#47 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#48 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#49 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#50 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32
(gdb) c
Continuing.[]
[New Thread 1784.0x658]
Thread 7 received signal SIGTRAP, Trace/breakpoint trap.]
0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x7c87f106 in KERNEL32!GetCurrencyFormatW ()
   from C:\WINDOWS\system32\kernel32.dll
(gdb) bt
#0  0x7c87f106 in KERNEL32!GetCurrencyFormatW ()
   from C:\WINDOWS\system32\kernel32.dll
#1  0x7c84b7ed in SetUnhandledExceptionFilter ()
   from C:\WINDOWS\system32\kernel32.dll
#2  0x77c34878 in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#3  0x00000409 in ?? ()
#4  0x00000100 in ?? ()
#5  0x1df1f61c in ?? ()
#6  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
#7  0x77c46293 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#8  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#9  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150
#10 <lambda(const cooked_index_entry*, const cooked_index_entry*)>::operator()
    (__closure=<optimized out>, b=<optimized out>, a=<optimized out>)
    at dwarf2/cooked-index.c:249
#11 __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >::operator()<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> > > (this=<optimized out>, __it2=..., __it1=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/predefined_ops.h:143
#12 std::__unguarded_partition<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__pivot=...,
    __last=<error reading variable: Cannot access memory at address 0xc5>,
    __first=0x21fe6e30, __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1904
#13 std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__last=0x37f054d0, __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1922
#14 std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >)
    (__first=0x20000184, __first@entry=0x38289370,
    __last=__last@entry=0x37025390, __depth_limit=29, __depth_limit@entry=31,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1952
#15 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x360728f0,
    __last=__last@entry=0x37025390, __depth_limit=31, __depth_limit@entry=32,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#16 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37882f10,
    __last=__last@entry=0x37025390, __depth_limit=32, __depth_limit@entry=33,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#17 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x39e88b90,
    __last=__last@entry=0x37025390, __depth_limit=33, __depth_limit@entry=34,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#18 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3a79d5b0,
    __last=__last@entry=0x37025390, __depth_limit=34, __depth_limit@entry=35,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#19 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x36f3c430,
    __last=__last@entry=0x37025390, __depth_limit=35, __depth_limit@entry=36,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#20 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3650ee10,
    __last=__last@entry=0x37025390, __depth_limit=36, __depth_limit@entry=37,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#21 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x359aee30, __last=__last@entry=0x0,
    __depth_limit=37, __depth_limit@entry=39, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#22 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3873cf10, __last=__last@entry=0x0,
    __depth_limit=39, __depth_limit@entry=40, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#23 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x2145fb08, __last=__last@entry=0x0,
    __depth_limit=40, __depth_limit@entry=41, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#24 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37e76f10, __last=__last@entry=0x0,
    __depth_limit=41, __depth_limit@entry=42, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#25 0x00511672 in std::__sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__comp=..., __last=..., __first=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1967
#26 std::sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > (__last=..., __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:4860
#27 cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:246
#28 0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#29 std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#30 std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#31 gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#32 cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#33 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#34 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#35 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#36 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#37 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#38 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#39 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#40 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#41 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#42 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#43 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#44 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#45 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#46 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#47 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#48 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#49 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#50 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32
(gdb) c
Continuing.
[][New Thread 1784.0x858]
Thread 8 received signal SIGTRAP, Trace/breakpoint trap.]
0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x77c3745a in strerror () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0  0x77c3745a in strerror () from C:\WINDOWS\system32\msvcrt.dll
#1  0x77c34721 in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#2  0x00000001 in ?? ()
#3  0x1e777860 in ?? ()
#4  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
#5  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#6  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#7  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150
#8  <lambda(const cooked_index_entry*, const cooked_index_entry*)>::operator()
    (__closure=<optimized out>, b=<optimized out>, a=<optimized out>)
    at dwarf2/cooked-index.c:249
#9  __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >::operator()<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> > > (this=<optimized out>, __it2=..., __it1=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/predefined_ops.h:143
#10 std::__unguarded_partition<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__pivot=..., __last=0x1, __first=0x215c8d48, __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1904
#11 std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__last=0x38137a30, __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1922
#12 std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >)
    (__first=<error reading variable: Cannot access memory at address 0x1>,
    __first@entry=0x38c70050, __last=__last@entry=0x0, __depth_limit=38,
    __depth_limit@entry=41, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1952
#13 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37e76f10, __last=__last@entry=0x0,
    __depth_limit=41, __depth_limit@entry=42, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#14 0x00511672 in std::__sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__comp=..., __last=..., __first=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1967
#15 std::sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > (__last=..., __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:4860
#16 cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:246
#17 0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#18 std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#19 std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#20 gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#21 cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#22 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#23 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#24 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#25 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#26 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#27 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#28 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#29 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#30 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#31 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#32 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#33 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#34 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#35 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#36 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#37 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#38 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#39 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32(gdb) cContinuing.[][New Thread 1784.0x14b0]Thread 9 received signal SIGTRAP, Trace/breakpoint trap.[Switching to Thread 1784.0x14b0]0x7c90120f in ntdll!DbgBreakPoint () from C:\Wl(gdb) thread 1[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x7c80a2ad in WideCharToMultiByte () from C:\WINDOWS\system32\kernel32.dll(t
#0  0x7c80a2ad in WideCharToMultiByte () from C:\WINDOWS\system32\kernel32.dll
#1  0x7c80a294 in WideCharToMultiByte () from C:\WINDOWS\system32\kernel32.dll
#2  0x77c3494b in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#3  0x000004e4 in ?? ()
#4  0x00000000 in ?? ()
(gdb) c
Continuing.
[Thread 1784.0x14b0 exited with code 0]
[New Thread 1784.0x1198]
Thread 10 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1784.0x1198]
0x7c90120f in ntdll!DbgBreakPoint () from C:\Wl
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x7c80d261 in KERNEL32!CompareStringA ()
   from C:\WINDOWS\system32\kernel32.dll
(gdb) bt
#0  0x7c80d261 in KERNEL32!CompareStringA ()
   from C:\WINDOWS\system32\kernel32.dll
#1  0x7c84c59c in SetUnhandledExceptionFilter ()
   from C:\WINDOWS\system32\kernel32.dll
#2  0x77c3485e in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#3  0x000004e4 in ?? ()
#4  0x00000001 in ?? ()
#5  0x1df1f930 in ?? ()
#6  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
#7  0x77c46293 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#8  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#9  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150
#10 <lambda(const cooked_index_entry*, const cooked_index_entry*)>::operator()
    (__closure=<optimized out>, b=<optimized out>, a=<optimized out>)
    at dwarf2/cooked-index.c:249
#11 __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >::operator()<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> > > (this=<optimized out>, __it2=..., __it1=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/predefined_ops.h:143
#12 std::__unguarded_partition<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__pivot=...,
    __last=<error reading variable: Cannot access memory at address 0xc5>,
    __first=0x3a9973b0, __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1904
#13 std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__last=0x37ca1d90, __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1922
#14 std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >)
    (__first=non-dereferenceable iterator for std::vector,
    __first@entry=0x39dec558, __last=__last@entry=0x0, __depth_limit=40,
    __depth_limit@entry=42, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1952
#15 0x00511672 in std::__sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__comp=..., __last=..., __first=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1967
#16 std::sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > (__last=..., __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:4860
#17 cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:246
#18 0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#19 std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#20 std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#21 gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#22 cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#23 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#24 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#25 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#26 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#27 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#28 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#29 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#30 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#31 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#32 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#33 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#34 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#35 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#36 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#37 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#38 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#39 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#40 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32
(gdb) c
Continuing.
[][New Thread 1784.0xa80]
Thread 11 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1784.0xa80]
0x7c90120f in ntdll!DbgBreakPoint () from C:\WIl
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x77c1c94c in tolower () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0  0x77c1c94c in tolower () from C:\WINDOWS\system32\msvcrt.dll
#1  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#2  0x005107a5 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#3  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150
#4  <lambda(const cooked_index_entry*, const cooked_index_entry*)>::operator()
    (__closure=<optimized out>, b=<optimized out>, a=<optimized out>)
    at dwarf2/cooked-index.c:249
#5  __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >::operator()<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> > > (this=<optimized out>,
    __it2=<error reading variable: Cannot access memory at address 0x1>,
    __it1=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/predefined_ops.h:143
#6  std::__unguarded_partition<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__pivot=..., __last=0x38307dd0, __first=0x1, __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1901
#7  std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__last=0x39e59d50, __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1922
#8  std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >)
    (__first=<error reading variable: Cannot access memory at address 0x1>,
    __first@entry=0x3ac77eb0, __last=__last@entry=0x39e59d50,
    __depth_limit=27, __depth_limit@entry=28, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1952
#9  0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3abc3c70,
    __last=__last@entry=0x3874e710, __depth_limit=28, __depth_limit@entry=32,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#10 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3827b4d0,
    __last=__last@entry=0x222e9a90, __depth_limit=32, __depth_limit@entry=36,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#11 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3661d6d0,
    __last=__last@entry=0x37ca1d90, __depth_limit=36, __depth_limit@entry=39,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#12 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x374d6370,
    __last=__last@entry=0x37ca1d90, __depth_limit=39, __depth_limit@entry=40,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#13 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x39dec558, __last=__last@entry=0x0,
    __depth_limit=40, __depth_limit@entry=42, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#14 0x00511672 in std::__sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__comp=..., __last=..., __first=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1967
#15 std::sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > (__last=..., __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:4860
#16 cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:246
#17 0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#18 std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#19 std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#20 gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#21 cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#22 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#23 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#24 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#25 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#26 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#27 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#28 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#29 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#30 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#31 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#32 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#33 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#34 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#35 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#36 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#37 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#38 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#39 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32
(gdb) c
Continuing.
[]
[New Thread 1784.0x960]
Thread 12 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1784.0x960]
0x7c90120f in ntdll!DbgBreakPoint () from C:\WIl
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x7c80cf3e in LCMapStringW () from C:\WINDOWS\system32\kernel32.dll
(gdb) bt
#0  0x7c80cf3e in LCMapStringW () from C:\WINDOWS\system32\kernel32.dll
#1  0x7c80ced5 in LCMapStringW () from C:\WINDOWS\system32\kernel32.dll
#2  0x77c34928 in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#3  0x00000409 in ?? ()
#4  0x00000100 in ?? ()
#5  0x1df1f69c in ?? ()
#6  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
#7  0x77c46293 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#8  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#9  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150
#10 <lambda(const cooked_index_entry*, const cooked_index_entry*)>::operator()
    (__closure=<optimized out>, b=<optimized out>, a=<optimized out>)
    at dwarf2/cooked-index.c:249
#11 __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >::operator()<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> > > (this=<optimized out>, __it2=..., __it1=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/predefined_ops.h:143
#12 std::__unguarded_partition<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__pivot=..., __last=0x1200110, __first=0x3899f5f0, __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1904
#13 std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__last=0x37a1b970, __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1922
#14 std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >)
    (
    __first=<error reading variable: Cannot access memory at address 0xfffffffc>, __first@entry=0x3a1d61d0, __last=__last@entry=0x378bacd0,
    __depth_limit=26, __depth_limit@entry=29, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1952
#15 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x35839d10,
    __last=__last@entry=0x36d21dd0, __depth_limit=29, __depth_limit@entry=31,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#16 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3ab55610,
    __last=__last@entry=0x3ae09350, __depth_limit=31, __depth_limit@entry=33,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#17 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3ac09450,
    __last=__last@entry=0x3ae09350, __depth_limit=33, __depth_limit@entry=34,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#18 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x398e5790,
    __last=__last@entry=0x370a5810, __depth_limit=34, __depth_limit@entry=36,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#19 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x382a4bf0,
    __last=__last@entry=0x370a5810, __depth_limit=36, __depth_limit@entry=37,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#20 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37854070,
    __last=__last@entry=0x370a5810, __depth_limit=37, __depth_limit@entry=38,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#21 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x39721f30,
    __last=__last@entry=0x37ca1d90, __depth_limit=38, __depth_limit@entry=40,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#22 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x39dec558, __last=__last@entry=0x0,
    __depth_limit=40, __depth_limit@entry=42, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#23 0x00511672 in std::__sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__comp=..., __last=..., __first=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1967
#24 std::sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > (__last=..., __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:4860
#25 cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:246
#26 0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#27 std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#28 std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#29 gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#30 cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#31 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#32 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#33 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#34 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#35 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#36 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#37 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#38 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#39 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#40 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#41 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#42 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#43 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#44 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#45 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#46 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#47 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#48 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32
(gdb) c
Continuing.
[][New Thread 1784.0xcd4]
Thread 13 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1784.0xcd4]
0x7c90120f in ntdll!DbgBreakPoint () from C:\WIl
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x7c84c425 in SetUnhandledExceptionFilter ()
   from C:\WINDOWS\system32\kernel32.dll
(gdb) bt
#0  0x7c84c425 in SetUnhandledExceptionFilter ()
   from C:\WINDOWS\system32\kernel32.dll
#1  0x77c3485e in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#2  0x000004e4 in ?? ()
#3  0x00000001 in ?? ()
#4  0x1df1f7e8 in ?? ()
#5  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
#6  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#7  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#8  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150
#9  <lambda(const cooked_index_entry*, const cooked_index_entry*)>::operator()
    (__closure=<optimized out>, b=<optimized out>, a=<optimized out>)
    at dwarf2/cooked-index.c:249
#10 __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >::operator()<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> > > (this=<optimized out>, __it2=..., __it1=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/predefined_ops.h:143
#11 std::__unguarded_partition<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__pivot=...,
    __last=<error reading variable: Cannot access memory at address 0x4e4>,
    __first=0x22335270, __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1904
#12 std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__last=0x362bf090, __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1922
#13 std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >)
    (__first=non-dereferenceable iterator for std::vector,
    __first@entry=0x37f6d030, __last=__last@entry=0x362bf090,
    __depth_limit=32, __depth_limit@entry=33, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1952
#14 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3a82d6d0,
    __last=__last@entry=0x362bf090, __depth_limit=33, __depth_limit@entry=34,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#15 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x38672770,
    __last=__last@entry=0x21efc390, __depth_limit=34, __depth_limit@entry=36,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#16 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x36e3d330,
    __last=__last@entry=0x21efc390, __depth_limit=36, __depth_limit@entry=37,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#17 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x363c9fb0,
    __last=__last@entry=0x37ca1d90, __depth_limit=37, __depth_limit@entry=40,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#18 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x39dec558, __last=__last@entry=0x0,
    __depth_limit=40, __depth_limit@entry=42, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#19 0x00511672 in std::__sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__comp=..., __last=..., __first=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1967
#20 std::sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > (__last=..., __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:4860
#21 cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:246
#22 0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#23 std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#24 std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#25 gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#26 cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#27 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#28 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#29 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#30 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#31 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#32 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#33 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#34 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#35 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#36 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#37 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#38 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#39 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#40 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#41 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#42 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#43 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#44 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32
(gdb) c
Continuing.
[][New Thread 1784.0x1660]
Thread 14 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1784.0x1660]
0x7c90120f in ntdll!DbgBreakPoint () from C:\Wl
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x77c34853 in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0  0x77c34853 in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#1  0x1df1f868 in ?? ()
#2  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
#3  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#4  0x005107a5 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#5  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150
#6  <lambda(const cooked_index_entry*, const cooked_index_entry*)>::operator()
    (__closure=<optimized out>, b=<optimized out>, a=<optimized out>)
    at dwarf2/cooked-index.c:249
#7  __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >::operator()<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> > > (this=<optimized out>, __it2=non-dereferenceable iterator for std::vector,
    __it1=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/predefined_ops.h:143
#8  std::__unguarded_partition<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__pivot=..., __last=0x37ca3ab0,
    __first=<error reading variable: Cannot access memory at address 0x1>,
    __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1901
#9  std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__last=0x3a70fad0, __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1922
#10 std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >)
    (__first=non-dereferenceable iterator for std::vector,
    __first@entry=0x35ac8a70, __last=__last@entry=0x3a70fad0,
    __depth_limit=33, __depth_limit@entry=34, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1952
#11 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x3adf23d0,
    __last=__last@entry=0x3a52eb30, __depth_limit=34, __depth_limit@entry=38,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#12 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x35fbce50,
    __last=__last@entry=0x3a52eb30, __depth_limit=38, __depth_limit@entry=39,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#13 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37418b10, __last=__last@entry=0x0,
    __depth_limit=39, __depth_limit@entry=42, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#14 0x00511672 in std::__sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__comp=..., __last=..., __first=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1967
#15 std::sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > (__last=..., __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:4860
#16 cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:246
#17 0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#18 std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#19 std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#20 gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#21 cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#22 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#23 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#24 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#25 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#26 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#27 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#28 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#29 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#30 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#31 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#32 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#33 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#34 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#35 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#36 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#37 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#38 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#39 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32
(gdb) c
Continuing.
[][New Thread 1784.0x1438]
Thread 15 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1784.0x1438]
0x7c90120f in ntdll!DbgBreakPoint () from C:\Wl
(gdb) thread 1
[Switching to thread 1 (Thread 1784.0x10c4)]
#0  0x7c80cf33 in LCMapStringW () from C:\WINDOWS\system32\kernel32.dll(gdb) bt
#0  0x7c80cf33 in LCMapStringW () from C:\WINDOWS\system32\kernel32.dll
#1  0x7c80ced5 in LCMapStringW () from C:\WINDOWS\system32\kernel32.dll
#2  0x77c34928 in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#3  0x00000409 in ?? ()
#4  0x00000100 in ?? ()
#5  0x1df1f794 in ?? ()
#6  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
#7  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#8  0x005107a5 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#9  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150
#10 <lambda(const cooked_index_entry*, const cooked_index_entry*)>::operator()
    (__closure=<optimized out>, b=<optimized out>, a=<optimized out>)
    at dwarf2/cooked-index.c:249
#11 __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >::operator()<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> > > (this=<optimized out>,
    __it2=<error reading variable: Cannot access memory at address 0xfffffffc>,)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/predefined_ops.h:143
#12 std::__unguarded_partition<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__pivot=..., __last=0x3a5cc3d0, __first=0x1200110, __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1901
#13 std::__unguarded_partition_pivot<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__last=0x38766548, __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1922
#14 std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >)
    (
    __first=<error reading variable: Cannot access memory at address 0xfffffffc>, __first@entry=0x36236fb0, __last=__last@entry=0x38766548,
    __depth_limit=32, __depth_limit@entry=33, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1952
#15 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37153810,
    __last=__last@entry=0x35d4bcd0, __depth_limit=33, __depth_limit@entry=35,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#16 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x37f51450,
    __last=__last@entry=0x37bf6db0, __depth_limit=35, __depth_limit@entry=37,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#17 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x399a1690,
    __last=__last@entry=0x37bf6db0, __depth_limit=37, __depth_limit@entry=38,
    __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#18 0x00510818 in std::__introsort_loop<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > >(__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, __gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*, std::allocator<cooked_index_entry*> > >, int, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> >) (__first=__first@entry=0x35bbad90, __last=__last@entry=0x0,
    __depth_limit=38, __depth_limit@entry=42, __comp=__comp@entry=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1953
#19 0x00511672 in std::__sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, __gnu_cxx::__ops::_Iter_comp_iter<cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > > (__comp=..., __last=..., __first=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:1967
#20 std::sort<__gnu_cxx::__normal_iterator<cooked_index_entry**, std::vector<cooked_index_entry*> >, cooked_index::do_finalize()::<lambda(const cooked_index_entry*, const cooked_index_entry*)> > (__last=..., __first=..., __comp=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/stl_algo.h:4860
#21 cooked_index::do_finalize (this=<optimized out>)
    at dwarf2/cooked-index.c:246
#22 0x00511912 in <lambda()>::operator() (__closure=0x1df1fa10)
    at dwarf2/cooked-index.c:123
#23 std::_Function_handler<void(), cooked_index::finalize()::<lambda()> >::_M_invoke (__functor=...)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:300
#24 std::function<void ()>::operator()() const (this=0x1df1fa10)
    at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/std_function.h:690
#25 gdb::thread_pool::post_task(std::function<void ()>&&) (
    this=<optimized out>, func=...) at ./../gdbsupport/thread-pool.h:132
#26 cooked_index::finalize (this=<optimized out>) at dwarf2/cooked-index.c:124
#27 0x0051198f in cooked_index_vector::cooked_index_vector (this=0x217fcdd8,
    vec=...) at d:/usr/lib/gcc/mingw32/9.2.0/include/c++/bits/unique_ptr.h:154
#28 0x00a08df6 in dwarf2_build_psymtabs_hard (per_objfile=<optimized out>)
    at dwarf2/read.c:7185
#29 dwarf2_build_psymtabs (objfile=<optimized out>) at dwarf2/read.c:5434
#30 cooked_index_functions::read_partial_symbols (this=<optimized out>,
    objfile=<optimized out>) at dwarf2/read.c:18593
#31 0x00782929 in objfile::require_partial_symbols (
    this=this@entry=0x1e7764f8, verbose=<optimized out>, verbose@entry=false)
    at symfile-debug.c:541
#32 0x0078a99e in read_symbols (objfile=objfile@entry=0x1e7764f8,
    add_flags=..., add_flags@entry=...) at symfile.c:795
#33 0x00789e50 in syms_from_objfile_1 (add_flags=..., addrs=0x1df1fc70,
    objfile=0x1e7764f8) at symfile.c:968
#34 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x1e7764f8) at symfile.c:985
#35 symbol_file_add_with_addrs (abfd=..., name=<optimized out>,
    name@entry=0x1e6c46a8 "./gdb.exe", add_flags=..., add_flags@entry=...,
    addrs=<optimized out>, addrs@entry=0x0, flags=flags@entry=...,
    parent=<optimized out>, parent@entry=0x0) at symfile.c:1088
#36 0x0078bbd8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x0,
    add_flags=..., name=0x1e6c46a8 "./gdb.exe", abfd=...) at symfile.c:1168
#37 symbol_file_add (name=name@entry=0x1e6c46a8 "./gdb.exe", add_flags=...,
    add_flags@entry=..., addrs=addrs@entry=0x0, flags=..., flags@entry=...)
    at symfile.c:1181
#38 0x0078bc51 in symbol_file_add_main_1 (args=0x1e6c46a8 "./gdb.exe",
    add_flags=..., flags=..., reloff=0) at symfile.c:1205
#39 0x0078bce5 in symbol_file_add_main (args=0x1e6c46a8 "./gdb.exe",
    add_flags=...) at symfile.c:1196
#40 0x00663ce2 in catch_command_errors (
    command=command@entry=0x663c90 <symbol_file_add_main_adapter(char const*, int)>, arg=0x1e6c46a8 "./gdb.exe", from_tty=1,
    do_bp_actions=do_bp_actions@entry=false) at main.c:513
#41 0x00666746 in captured_main_1 (context=<optimized out>,
    context@entry=0x1df1ff64) at main.c:1213
#42 0x00666878 in captured_main (data=0x1df1ff64) at main.c:1320
#43 gdb_main (args=args@entry=0x1df1ff64) at main.c:1345
#44 0x00a7ceba in main (argc=3, argv=0x1e6c0d60) at gdb.c:32(gdb) cContinuing.

Re: Two observations using GDB 13 snapshot

[Simon Marchi]

On 12/29/22 14:13, Eli Zaretskii via Gdb-patches wrote:
>> From: Tom Tromey <tom@tromey.com>
>> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org,
>>   luis.machado@arm.com
>> Date: Thu, 29 Dec 2022 11:17:27 -0700
>>
>> I wonder if just randomly interrupting gdb a few times during that 2
>> minutes and doing a "bt" would be more informative.
> 
> Done, see the attached.
> 

It looks like we spend a lot of time sorting the vector of index
entries.  We spend a lot of time in tolower.  Googling a bit, it looks
like tolower can be slow on Windows when a locale (other than "C") is
used:

https://stackoverflow.com/questions/36686381/windows-c-runtime-toupper-slow-when-locale-set
https://bugs.php.net/bug.php?id=45265

Simon

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> Date: Thu, 29 Dec 2022 15:22:31 -0500
> Cc: gdb-patches@sourceware.org, luis.machado@arm.com
> From: Simon Marchi <simark@simark.ca>
> 
> 
> It looks like we spend a lot of time sorting the vector of index
> entries.  We spend a lot of time in tolower.

Why do we need to use tolower in sorting here? is the sorting order
case-insensitive or something?

> Googling a bit, it looks
> like tolower can be slow on Windows when a locale (other than "C") is
> used:
> 
> https://stackoverflow.com/questions/36686381/windows-c-runtime-toupper-slow-when-locale-set
> https://bugs.php.net/bug.php?id=45265

I couldn't see any numbers there about the performance of tolower
itself, i.e. how many ms per call does it take on Windows vs glibc.
But if someone can show a patch to try to eliminate the calls to
tolower, I can try and see if it affects the processing time in this
scenario.

Thanks.

Re: Two observations using GDB 13 snapshot

[Christian Biesinger]

On Fri, Dec 30, 2022 at 9:32 AM Eli Zaretskii via Gdb-patches
<gdb-patches@sourceware.org> wrote:
>
> > Date: Thu, 29 Dec 2022 15:22:31 -0500
> > Cc: gdb-patches@sourceware.org, luis.machado@arm.com
> > From: Simon Marchi <simark@simark.ca>
> > Googling a bit, it looks
> > like tolower can be slow on Windows when a locale (other than "C") is
> > used:
> >
> > https://stackoverflow.com/questions/36686381/windows-c-runtime-toupper-slow-when-locale-set
> > https://bugs.php.net/bug.php?id=45265
>
> I couldn't see any numbers there about the performance of tolower
> itself, i.e. how many ms per call does it take on Windows vs glibc.
> But if someone can show a patch to try to eliminate the calls to
> tolower, I can try and see if it affects the processing time in this
> scenario.

Seems like that could be tested by running gdb with LANG=C and/or
commenting out the setlocale calls in gdb/main.c?

Christian

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Tue, 3 Jan 2023 14:44:56 -0500
> Cc: Simon Marchi <simark@simark.ca>, tom@tromey.com, gdb-patches@sourceware.org, 
> 	luis.machado@arm.com
> 
> > > https://stackoverflow.com/questions/36686381/windows-c-runtime-toupper-slow-when-locale-set
> > > https://bugs.php.net/bug.php?id=45265
> >
> > I couldn't see any numbers there about the performance of tolower
> > itself, i.e. how many ms per call does it take on Windows vs glibc.
> > But if someone can show a patch to try to eliminate the calls to
> > tolower, I can try and see if it affects the processing time in this
> > scenario.
> 
> Seems like that could be tested by running gdb with LANG=C and/or
> commenting out the setlocale calls in gdb/main.c?

Setting LANG in the environment doesn't have any effect on Windows,
since the Windows version of setlocale is insensitive to LANG and LC_*
environment variables.

Re: Two observations using GDB 13 snapshot

[Christian Biesinger]

On Tue, Jan 3, 2023 at 3:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Christian Biesinger <cbiesinger@google.com>
> > Date: Tue, 3 Jan 2023 14:44:56 -0500
> > Cc: Simon Marchi <simark@simark.ca>, tom@tromey.com, gdb-patches@sourceware.org,
> >       luis.machado@arm.com
> >
> > > > https://stackoverflow.com/questions/36686381/windows-c-runtime-toupper-slow-when-locale-set
> > > > https://bugs.php.net/bug.php?id=45265
> > >
> > > I couldn't see any numbers there about the performance of tolower
> > > itself, i.e. how many ms per call does it take on Windows vs glibc.
> > > But if someone can show a patch to try to eliminate the calls to
> > > tolower, I can try and see if it affects the processing time in this
> > > scenario.
> >
> > Seems like that could be tested by running gdb with LANG=C and/or
> > commenting out the setlocale calls in gdb/main.c?
>
> Setting LANG in the environment doesn't have any effect on Windows,
> since the Windows version of setlocale is insensitive to LANG and LC_*
> environment variables.

Well you could still try commenting out the setlocale call.

In terms of the code, may be worth trying TOLOWER from
include/safe-ctype.h instead of tolower()

Christian

Re: Two observations using GDB 13 snapshot

[Simon Marchi]

On 1/3/23 15:34, Christian Biesinger via Gdb-patches wrote:
> On Tue, Jan 3, 2023 at 3:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> From: Christian Biesinger <cbiesinger@google.com>
>>> Date: Tue, 3 Jan 2023 14:44:56 -0500
>>> Cc: Simon Marchi <simark@simark.ca>, tom@tromey.com, gdb-patches@sourceware.org,
>>>       luis.machado@arm.com
>>>
>>>>> https://stackoverflow.com/questions/36686381/windows-c-runtime-toupper-slow-when-locale-set
>>>>> https://bugs.php.net/bug.php?id=45265
>>>>
>>>> I couldn't see any numbers there about the performance of tolower
>>>> itself, i.e. how many ms per call does it take on Windows vs glibc.
>>>> But if someone can show a patch to try to eliminate the calls to
>>>> tolower, I can try and see if it affects the processing time in this
>>>> scenario.
>>>
>>> Seems like that could be tested by running gdb with LANG=C and/or
>>> commenting out the setlocale calls in gdb/main.c?
>>
>> Setting LANG in the environment doesn't have any effect on Windows,
>> since the Windows version of setlocale is insensitive to LANG and LC_*
>> environment variables.
> 
> Well you could still try commenting out the setlocale call.
> 
> In terms of the code, may be worth trying TOLOWER from
> include/safe-ctype.h instead of tolower()

The tolower call is inside strcasecmp, we don't call tolower directly:

#0  0x77c348d5 in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#1  0x77c348cd in msvcrt!__crtLCMapStringA ()
   from C:\WINDOWS\system32\msvcrt.dll
#2  0x77c30045 in wmktemp () from C:\WINDOWS\system32\msvcrt.dll
#3  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
#4  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
#5  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
    at d:/usr/include/strings.h:92
#6  cooked_index_entry::operator< (this=<optimized out>, other=...)
    at ./dwarf2/cooked-index.h:150

It would be interesting to change that strcasecmp call to strcmp, just
to see if it makes an impact on the performance.  Whether or not that
would be correct is another thing, but it would help see if that
strcasecmp / tolower call is really at fault here.

Simon

Re: Two observations using GDB 13 snapshot

[Christian Biesinger]

On Tue, Jan 3, 2023 at 4:34 PM Simon Marchi <simark@simark.ca> wrote:
>
>
>
> On 1/3/23 15:34, Christian Biesinger via Gdb-patches wrote:
> > On Tue, Jan 3, 2023 at 3:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >>> From: Christian Biesinger <cbiesinger@google.com>
> >>> Date: Tue, 3 Jan 2023 14:44:56 -0500
> >>> Cc: Simon Marchi <simark@simark.ca>, tom@tromey.com, gdb-patches@sourceware.org,
> >>>       luis.machado@arm.com
> >>>
> >>>>> https://stackoverflow.com/questions/36686381/windows-c-runtime-toupper-slow-when-locale-set
> >>>>> https://bugs.php.net/bug.php?id=45265
> >>>>
> >>>> I couldn't see any numbers there about the performance of tolower
> >>>> itself, i.e. how many ms per call does it take on Windows vs glibc.
> >>>> But if someone can show a patch to try to eliminate the calls to
> >>>> tolower, I can try and see if it affects the processing time in this
> >>>> scenario.
> >>>
> >>> Seems like that could be tested by running gdb with LANG=C and/or
> >>> commenting out the setlocale calls in gdb/main.c?
> >>
> >> Setting LANG in the environment doesn't have any effect on Windows,
> >> since the Windows version of setlocale is insensitive to LANG and LC_*
> >> environment variables.
> >
> > Well you could still try commenting out the setlocale call.
> >
> > In terms of the code, may be worth trying TOLOWER from
> > include/safe-ctype.h instead of tolower()
>
> The tolower call is inside strcasecmp, we don't call tolower directly:
>
> #0  0x77c348d5 in msvcrt!__crtLCMapStringA ()
>    from C:\WINDOWS\system32\msvcrt.dll
> #1  0x77c348cd in msvcrt!__crtLCMapStringA ()
>    from C:\WINDOWS\system32\msvcrt.dll
> #2  0x77c30045 in wmktemp () from C:\WINDOWS\system32\msvcrt.dll
> #3  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
> #4  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
> #5  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
>     at d:/usr/include/strings.h:92
> #6  cooked_index_entry::operator< (this=<optimized out>, other=...)
>     at ./dwarf2/cooked-index.h:150
>
> It would be interesting to change that strcasecmp call to strcmp, just
> to see if it makes an impact on the performance.  Whether or not that
> would be correct is another thing, but it would help see if that
> strcasecmp / tolower call is really at fault here.

It looks like libiberty has a strcasecmp.c that could work, though I
am not sure how one is expected to make sure that libiberty's
strcasecmp is used.

Christian

Re: Two observations using GDB 13 snapshot

[Tom Tromey]

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

Simon> It would be interesting to change that strcasecmp call to strcmp, just
Simon> to see if it makes an impact on the performance.  Whether or not that
Simon> would be correct is another thing, but it would help see if that
Simon> strcasecmp / tolower call is really at fault here.

My series to fix the template lookup problem avoids strcasecmp in favor
of a hand-written alternative.  So, I guess it's possible it would fix
this bug as well.  The patch that does this in particular is:

https://sourceware.org/pipermail/gdb-patches/2022-December/194799.html

I wonder if it's possible to do the sort case-sensitively.  I thought
this was for Fortran and/or Ada, but I'm not really sure.  For instance
it could also possibly be solved by case-folding the lookup name.  At
least, that's true for Ada, because GNAT already case-folds the DWARF
names.  Not sure about Fortran compilers.  Anyway, also not something
I'd want to experiment with just before the release.

Tom

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> Date: Tue, 3 Jan 2023 16:34:53 -0500
> Cc: tom@tromey.com, gdb-patches@sourceware.org, luis.machado@arm.com
> From: Simon Marchi <simark@simark.ca>
> 
> > In terms of the code, may be worth trying TOLOWER from
> > include/safe-ctype.h instead of tolower()
> 
> The tolower call is inside strcasecmp, we don't call tolower directly:
> 
> #0  0x77c348d5 in msvcrt!__crtLCMapStringA ()
>    from C:\WINDOWS\system32\msvcrt.dll
> #1  0x77c348cd in msvcrt!__crtLCMapStringA ()
>    from C:\WINDOWS\system32\msvcrt.dll
> #2  0x77c30045 in wmktemp () from C:\WINDOWS\system32\msvcrt.dll
> #3  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
> #4  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
> #5  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
>     at d:/usr/include/strings.h:92
> #6  cooked_index_entry::operator< (this=<optimized out>, other=...)
>     at ./dwarf2/cooked-index.h:150
> 
> It would be interesting to change that strcasecmp call to strcmp, just
> to see if it makes an impact on the performance.  Whether or not that
> would be correct is another thing, but it would help see if that
> strcasecmp / tolower call is really at fault here.

Looks like indeed strcasecmp is the culprit.  With the patch below,
which replaces strcasecmp with a simple case-insensitive comparison
that only works with ASCII, the phase of reading symbols from gdb.exe
goes down to just 6 seconds, which is basically the same time as with
GDB 12.

--- gdb/dwarf2/cooked-index.h~0	2022-12-17 03:47:12.000000000 +0200
+++ gdb/dwarf2/cooked-index.h	2023-01-04 20:00:04.052250000 +0200
@@ -35,6 +35,8 @@
 #include "dwarf2/tag.h"
 #include "gdbsupport/range-chain.h"
 
+#define my_tolower(c) (('A' <= (c) && (c) <= 'Z') ? ((c) - 'A' + 'a') : (c))
+
 struct dwarf2_per_cu_data;
 
 /* Flags that describe an entry in the index.  */
@@ -147,7 +149,20 @@ struct cooked_index_entry : public alloc
      entries.  */
   bool operator< (const cooked_index_entry &other) const
   {
+#if 0
     return strcasecmp (canonical, other.canonical) < 0;
+#else
+    const unsigned char *s1 = (unsigned char *)canonical, *s2 = (unsigned char *)other.canonical;
+
+    while (my_tolower(*s1) == my_tolower(*s2))
+      {
+	if (*s1 == 0)
+	  return false;
+	s1++;
+	s2++;
+      }
+    return (int)my_tolower(*s1) < (int)my_tolower(*s2);
+#endif
   }
 
   /* The name as it appears in DWARF.  This always points into one of

Re: Two observations using GDB 13 snapshot

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> Looks like indeed strcasecmp is the culprit.  With the patch below,
Eli> which replaces strcasecmp with a simple case-insensitive comparison
Eli> that only works with ASCII, the phase of reading symbols from gdb.exe
Eli> goes down to just 6 seconds, which is basically the same time as with
Eli> GDB 12.

Thank you.  Hopefully the other patch I have pending, which does
something similar, should have the same effect.

Tom

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Simon Marchi <simark@simark.ca>,  cbiesinger@google.com,
>   tom@tromey.com,  gdb-patches@sourceware.org,  luis.machado@arm.com
> Date: Wed, 04 Jan 2023 15:33:48 -0700
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> Looks like indeed strcasecmp is the culprit.  With the patch below,
> Eli> which replaces strcasecmp with a simple case-insensitive comparison
> Eli> that only works with ASCII, the phase of reading symbols from gdb.exe
> Eli> goes down to just 6 seconds, which is basically the same time as with
> Eli> GDB 12.
> 
> Thank you.  Hopefully the other patch I have pending, which does
> something similar, should have the same effect.

Thanks, I applied that patch (modulo the testsuite parts), and I can
confirm that it is almost as fast as the simple one I posted before:
7.5 sec vs 6.2 sec to read the symbols from gdb.exe.

However, what does this change mean in terms of GDB's support for
symbols with non-ASCII names?  AFAIU, libiberty's TOLOWER only handles
ASCII characters.

If it's okay for GDB to compare case-insensitively only ASCII
characters, then is the above patch mature enough to go to the gdb-13
branch?

Re: Two observations using GDB 13 snapshot

[Christian Biesinger]

On Thu, Jan 5, 2023 at 2:11 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Tom Tromey <tom@tromey.com>
> > Cc: Simon Marchi <simark@simark.ca>,  cbiesinger@google.com,
> >   tom@tromey.com,  gdb-patches@sourceware.org,  luis.machado@arm.com
> > Date: Wed, 04 Jan 2023 15:33:48 -0700
> >
> > >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> >
> > Eli> Looks like indeed strcasecmp is the culprit.  With the patch below,
> > Eli> which replaces strcasecmp with a simple case-insensitive comparison
> > Eli> that only works with ASCII, the phase of reading symbols from gdb.exe
> > Eli> goes down to just 6 seconds, which is basically the same time as with
> > Eli> GDB 12.
> >
> > Thank you.  Hopefully the other patch I have pending, which does
> > something similar, should have the same effect.
>
> Thanks, I applied that patch (modulo the testsuite parts), and I can
> confirm that it is almost as fast as the simple one I posted before:
> 7.5 sec vs 6.2 sec to read the symbols from gdb.exe.
>
> However, what does this change mean in terms of GDB's support for
> symbols with non-ASCII names?  AFAIU, libiberty's TOLOWER only handles
> ASCII characters.
>
> If it's okay for GDB to compare case-insensitively only ASCII
> characters, then is the above patch mature enough to go to the gdb-13
> branch?

If https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.name is
up-to-date (?), then
"This ABI does not yet specify a mangling for identifiers containing
characters outside of _A-Za-z0-9."

On the other hand, if
https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html#punycode-vs-utf-8
is to be believed, GCC/Clang/MSVC do use UTF-8 for symbol names. But I
don't think strcasecmp on Windows uses UTF-8?

Christian

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Thu, 5 Jan 2023 09:49:14 -0500
> Cc: Tom Tromey <tom@tromey.com>, simark@simark.ca, gdb-patches@sourceware.org, 
> 	luis.machado@arm.com
> 
> > If it's okay for GDB to compare case-insensitively only ASCII
> > characters, then is the above patch mature enough to go to the gdb-13
> > branch?
> 
> If https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.name is
> up-to-date (?), then
> "This ABI does not yet specify a mangling for identifiers containing
> characters outside of _A-Za-z0-9."
> 
> On the other hand, if
> https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html#punycode-vs-utf-8
> is to be believed, GCC/Clang/MSVC do use UTF-8 for symbol names. But I
> don't think strcasecmp on Windows uses UTF-8?

No, I think Windows would use UTF-16 instead.

Re: Two observations using GDB 13 snapshot

[Torbjorn SVENSSON]

On 2023-01-04 19:10, Eli Zaretskii via Gdb-patches wrote:
>> Date: Tue, 3 Jan 2023 16:34:53 -0500
>> Cc: tom@tromey.com, gdb-patches@sourceware.org, luis.machado@arm.com
>> From: Simon Marchi <simark@simark.ca>
>>
>>> In terms of the code, may be worth trying TOLOWER from
>>> include/safe-ctype.h instead of tolower()
>>
>> The tolower call is inside strcasecmp, we don't call tolower directly:
>>
>> #0  0x77c348d5 in msvcrt!__crtLCMapStringA ()
>>     from C:\WINDOWS\system32\msvcrt.dll
>> #1  0x77c348cd in msvcrt!__crtLCMapStringA ()
>>     from C:\WINDOWS\system32\msvcrt.dll
>> #2  0x77c30045 in wmktemp () from C:\WINDOWS\system32\msvcrt.dll
>> #3  0x77c1c992 in tolower () from C:\WINDOWS\system32\msvcrt.dll
>> #4  0x77c462a1 in stricmp () from C:\WINDOWS\system32\msvcrt.dll
>> #5  0x005107d3 in strcasecmp (__s2=<optimized out>, __s1=<optimized out>)
>>      at d:/usr/include/strings.h:92
>> #6  cooked_index_entry::operator< (this=<optimized out>, other=...)
>>      at ./dwarf2/cooked-index.h:150
>>
>> It would be interesting to change that strcasecmp call to strcmp, just
>> to see if it makes an impact on the performance.  Whether or not that
>> would be correct is another thing, but it would help see if that
>> strcasecmp / tolower call is really at fault here.
> 
> Looks like indeed strcasecmp is the culprit.  With the patch below,
> which replaces strcasecmp with a simple case-insensitive comparison
> that only works with ASCII, the phase of reading symbols from gdb.exe
> goes down to just 6 seconds, which is basically the same time as with
> GDB 12.
> 
> --- gdb/dwarf2/cooked-index.h~0	2022-12-17 03:47:12.000000000 +0200
> +++ gdb/dwarf2/cooked-index.h	2023-01-04 20:00:04.052250000 +0200
> @@ -35,6 +35,8 @@
>   #include "dwarf2/tag.h"
>   #include "gdbsupport/range-chain.h"
>   
> +#define my_tolower(c) (('A' <= (c) && (c) <= 'Z') ? ((c) - 'A' + 'a') : (c))
> +
>   struct dwarf2_per_cu_data;
>   
>   /* Flags that describe an entry in the index.  */
> @@ -147,7 +149,20 @@ struct cooked_index_entry : public alloc
>        entries.  */
>     bool operator< (const cooked_index_entry &other) const
>     {
> +#if 0
>       return strcasecmp (canonical, other.canonical) < 0;
> +#else
> +    const unsigned char *s1 = (unsigned char *)canonical, *s2 = (unsigned char *)other.canonical;
> +
> +    while (my_tolower(*s1) == my_tolower(*s2))
> +      {
> +	if (*s1 == 0)
> +	  return false;

Without any knowledge of the cooked_index_entry type or what it's 
supposed to do, I think the return statement here is problematic in the 
case where there are 2 cooked_index_entry instances contains the same 
case insensitive canonical strings. I'm not sure if this can happen, but 
it's just a thought.
It also appears that the old strcasecmp implementation would suffer the 
same limitation. To avoid the issue, I guess the address of the 2 
objects could be compared in order to get a stable result if there is no 
other property that is guaranteed to be unique for the 2 instances.

Kind regards,
Torbjörn

> +	s1++;
> +	s2++;
> +      }
> +    return (int)my_tolower(*s1) < (int)my_tolower(*s2);
> +#endif
>     }
>   
>     /* The name as it appears in DWARF.  This always points into one of

Re: Two observations using GDB 13 snapshot

[Tom Tromey]

Eli> Thanks, I applied that patch (modulo the testsuite parts), and I can
Eli> confirm that it is almost as fast as the simple one I posted before:
Eli> 7.5 sec vs 6.2 sec to read the symbols from gdb.exe.

Thank. you

Eli> However, what does this change mean in terms of GDB's support for
Eli> symbols with non-ASCII names?  AFAIU, libiberty's TOLOWER only handles
Eli> ASCII characters.

This scenario basically doesn't work anyway.  We could make it work,
probably, but so far there hasn't been much pressure to do that.

Eli> If it's okay for GDB to compare case-insensitively only ASCII
Eli> characters, then is the above patch mature enough to go to the gdb-13
Eli> branch?

I'm going to put my series there soon-ish, either if someone reviews it,
or just on my own if not.

Tom

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> Date: Sat, 17 Dec 2022 19:42:04 +0200
> From: Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>
> 
> 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.
> 
>   . The (top-gdb) prompt doesn't appear when debugging GDB with
>     itself.
> 
> Are these bugs or features?

With the first issue basically solved, what about the other one?  Can
someone tell me why "(top-gdb)" no longer shows, ot suggest where to
look for the reason?

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Eli Zaretskii via Gdb-patches wrote:

> With the first issue basically solved, what about the other one?  Can
> someone tell me why "(top-gdb)" no longer shows, ot suggest where to
> look for the reason?

What do you get instead?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Sat, 07 Jan 2023 10:14:55 +0100
> 
> On Jan 07 2023, Eli Zaretskii via Gdb-patches wrote:
> 
> > With the first issue basically solved, what about the other one?  Can
> > someone tell me why "(top-gdb)" no longer shows, ot suggest where to
> > look for the reason?
> 
> What do you get instead?

Just the usual "(gdb)".

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>
>> Date: Sat, 07 Jan 2023 10:14:55 +0100
>> 
>> On Jan 07 2023, Eli Zaretskii via Gdb-patches wrote:
>> 
>> > With the first issue basically solved, what about the other one?  Can
>> > someone tell me why "(top-gdb)" no longer shows, ot suggest where to
>> > look for the reason?
>> 
>> What do you get instead?
>
> Just the usual "(gdb)".

Full output, please.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: gdb-patches@sourceware.org
> Date: Sat, 07 Jan 2023 11:00:56 +0100
> 
> On Jan 07 2023, Eli Zaretskii wrote:
> 
> >> > With the first issue basically solved, what about the other one?  Can
> >> > someone tell me why "(top-gdb)" no longer shows, ot suggest where to
> >> > look for the reason?
> >> 
> >> What do you get instead?
> >
> > Just the usual "(gdb)".
> 
> Full output, please.

By "full output", did you mean the below?

  GNU gdb ((MinGW32 GDB)) 13.0.50.20221217-git
  Copyright (C) 2022 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "i686-pc-mingw32".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  <https://www.gnu.org/software/gdb/bugs/>.
  Find the GDB manual and other documentation resources online at:
      <http://www.gnu.org/software/gdb/documentation/>.

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./gdb.exe...
  (gdb)

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

Did you set auto-load safe-path in your ~/.gdbinit?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: gdb-patches@sourceware.org
> Date: Sat, 07 Jan 2023 14:04:28 +0100
> 
> Did you set auto-load safe-path in your ~/.gdbinit?

Yes, I did.  But (a) if I rename ~/.gdbinit to some other name, GDB 13
still shows the "(gdb)" prompt, not "(top-gdb)"; (b) GDB 12 does show
the "(top-gdb)" prompt with "auto-load safe path" in ~/.gdbinit (but
not without it); and (c) could you explain what does "auto-load
safe-path" have to do with the top-gdb prompt?

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Eli Zaretskii wrote:

> Yes, I did.  But (a) if I rename ~/.gdbinit to some other name, GDB 13
> still shows the "(gdb)" prompt, not "(top-gdb)";

Full output please.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: gdb-patches@sourceware.org
> Date: Sat, 07 Jan 2023 14:59:28 +0100
> 
> On Jan 07 2023, Eli Zaretskii wrote:
> 
> > Yes, I did.  But (a) if I rename ~/.gdbinit to some other name, GDB 13
> > still shows the "(gdb)" prompt, not "(top-gdb)";
> 
> Full output please.

There's no change:

  GNU gdb ((MinGW32 GDB)) 13.0.50.20221217-git
  Copyright (C) 2022 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "i686-pc-mingw32".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  <https://www.gnu.org/software/gdb/bugs/>.
  Find the GDB manual and other documentation resources online at:
      <http://www.gnu.org/software/gdb/documentation/>.

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./gdb.exe...
  (gdb)

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Eli Zaretskii wrote:

>   GNU gdb ((MinGW32 GDB)) 13.0.50.20221217-git
>   Copyright (C) 2022 Free Software Foundation, Inc.
>   License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>   This is free software: you are free to change and redistribute it.
>   There is NO WARRANTY, to the extent permitted by law.
>   Type "show copying" and "show warranty" for details.
>   This GDB was configured as "i686-pc-mingw32".
>   Type "show configuration" for configuration details.
>   For bug reporting instructions, please see:
>   <https://www.gnu.org/software/gdb/bugs/>.
>   Find the GDB manual and other documentation resources online at:
>       <http://www.gnu.org/software/gdb/documentation/>.
>
>   For help, type "help".
>   Type "apropos word" to search for commands related to "word"...
>   Reading symbols from ./gdb.exe...

Here you should see a warning:

warning: File "[...]/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

Does it help to copy gdb.exe to gdb and use that?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: gdb-patches@sourceware.org
> Date: Sat, 07 Jan 2023 15:23:35 +0100
> 
> On Jan 07 2023, Eli Zaretskii wrote:
> 
> >   GNU gdb ((MinGW32 GDB)) 13.0.50.20221217-git
> >   Copyright (C) 2022 Free Software Foundation, Inc.
> >   License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> >   This is free software: you are free to change and redistribute it.
> >   There is NO WARRANTY, to the extent permitted by law.
> >   Type "show copying" and "show warranty" for details.
> >   This GDB was configured as "i686-pc-mingw32".
> >   Type "show configuration" for configuration details.
> >   For bug reporting instructions, please see:
> >   <https://www.gnu.org/software/gdb/bugs/>.
> >   Find the GDB manual and other documentation resources online at:
> >       <http://www.gnu.org/software/gdb/documentation/>.
> >
> >   For help, type "help".
> >   Type "apropos word" to search for commands related to "word"...
> >   Reading symbols from ./gdb.exe...
> 
> Here you should see a warning:
> 
> warning: File "[...]/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> 
> Does it help to copy gdb.exe to gdb and use that?

Probably.  I did it the other way around: copied gdb-gdb.gdb to the
.libs subdirectory, and now the prompt is the expected (top-gdb).

So the problem is that we are now using libtool, and that causes the
GDB executable to be in a directory different from where gdb-gdb.gdb
is kept.

Joel, should the build procedure copy gdb-gdb.gdb to the .libs
subdirectory, where the GDB executable now lives?

Thanks.

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Eli Zaretskii wrote:

> So the problem is that we are now using libtool, and that causes the
> GDB executable to be in a directory different from where gdb-gdb.gdb
> is kept.

That does not happen for me.  Did you configure with --enable-shared?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> Date: Sat, 07 Jan 2023 16:29:09 +0200
> Cc: gdb-patches@sourceware.org
> X-Spam-Status: No, score=1.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
>  DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT,
>  RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS,
>  TXREP autolearn=no autolearn_force=no version=3.4.6
> From: Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>
> 
> > From: Andreas Schwab <schwab@linux-m68k.org>
> > Cc: gdb-patches@sourceware.org
> > Date: Sat, 07 Jan 2023 15:23:35 +0100
> > 
> > On Jan 07 2023, Eli Zaretskii wrote:
> > 
> > >   GNU gdb ((MinGW32 GDB)) 13.0.50.20221217-git
> > >   Copyright (C) 2022 Free Software Foundation, Inc.
> > >   License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > >   This is free software: you are free to change and redistribute it.
> > >   There is NO WARRANTY, to the extent permitted by law.
> > >   Type "show copying" and "show warranty" for details.
> > >   This GDB was configured as "i686-pc-mingw32".
> > >   Type "show configuration" for configuration details.
> > >   For bug reporting instructions, please see:
> > >   <https://www.gnu.org/software/gdb/bugs/>.
> > >   Find the GDB manual and other documentation resources online at:
> > >       <http://www.gnu.org/software/gdb/documentation/>.
> > >
> > >   For help, type "help".
> > >   Type "apropos word" to search for commands related to "word"...
> > >   Reading symbols from ./gdb.exe...
> > 
> > Here you should see a warning:
> > 
> > warning: File "[...]/gdb-gdb.gdb" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> > 
> > Does it help to copy gdb.exe to gdb and use that?
> 
> Probably.

Actually, it's impossible to do that, since the gdb directory already
includes a gdb.exe (which is a libtool wrapper).  Copying gdb-gdb.gdb
to .libs is thus the only way.

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: gdb-patches@sourceware.org
> Date: Sat, 07 Jan 2023 15:40:01 +0100
> 
> On Jan 07 2023, Eli Zaretskii wrote:
> 
> > So the problem is that we are now using libtool, and that causes the
> > GDB executable to be in a directory different from where gdb-gdb.gdb
> > is kept.
> 
> That does not happen for me.  Did you configure with --enable-shared?

No.  Why would I need to?  GDB is not a library, and doesn't build
libraries that need to be installed, AFAIK.

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: gdb-patches@sourceware.org
>> Date: Sat, 07 Jan 2023 15:40:01 +0100
>> 
>> On Jan 07 2023, Eli Zaretskii wrote:
>> 
>> > So the problem is that we are now using libtool, and that causes the
>> > GDB executable to be in a directory different from where gdb-gdb.gdb
>> > is kept.
>> 
>> That does not happen for me.  Did you configure with --enable-shared?
>
> No.  Why would I need to?

Without it, libtool should have no reason to put gdb in .libs.

> GDB is not a library, and doesn't build libraries that need to be
> installed, AFAIK.

So why does it create the gdb binary in .libs?  It is empty for me.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: gdb-patches@sourceware.org
> Date: Sat, 07 Jan 2023 16:40:15 +0100
> 
> On Jan 07 2023, Eli Zaretskii wrote:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: gdb-patches@sourceware.org
> >> Date: Sat, 07 Jan 2023 15:40:01 +0100
> >> 
> >> On Jan 07 2023, Eli Zaretskii wrote:
> >> 
> >> > So the problem is that we are now using libtool, and that causes the
> >> > GDB executable to be in a directory different from where gdb-gdb.gdb
> >> > is kept.
> >> 
> >> That does not happen for me.  Did you configure with --enable-shared?
> >
> > No.  Why would I need to?
> 
> Without it, libtool should have no reason to put gdb in .libs.

I see.  Well, here it is.

> > GDB is not a library, and doesn't build libraries that need to be
> > installed, AFAIK.
> 
> So why does it create the gdb binary in .libs?  It is empty for me.

I don't know.  Any libtool experts around here?

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> Date: Sat, 07 Jan 2023 18:10:26 +0200
> Cc: gdb-patches@sourceware.org
> From: Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>
> 
> > >> That does not happen for me.  Did you configure with --enable-shared?
> > >
> > > No.  Why would I need to?
> > 
> > Without it, libtool should have no reason to put gdb in .libs.
> 
> I see.  Well, here it is.

Could it be related to the warnings I got from libtool during the
build:


  /bin/sh ./libtool  --tag=CC    --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Wno-format -Werror  -O2 -gdwarf-4 -g3       -release `cat libtool-soversion`   -Wl,--stack,12582912 -o libbfd.la -rpath d:/usr/lib archive.lo archures.lo bfd.lo bfdio.lo bfdwin.lo  cache.lo coff-bfd.lo compress.lo corefile.lo elf-properties.lo  format.lo hash.lo init.lo libbfd.lo linker.lo merge.lo  opncls.lo reloc.lo section.lo simple.lo stab-syms.lo stabs.lo  syms.lo targets.lo binary.lo ihex.lo srec.lo tekhex.lo  verilog.lo `cat ofiles`  d:/usr/lib/libintl.a d:/usr/lib/libiconv.a  -lz

  *** Warning: Trying to link with static lib archive d:/usr/lib/libintl.a.
  *** I have the capability to make that library automatically link in when
  *** you link to this library.  But I can only do this if you have a
  *** shared version of the library, which you do not appear to have
  *** because the file extensions .a of this argument makes me believe
  *** that it is just a static archive that I should not use here.

  *** Warning: Trying to link with static lib archive d:/usr/lib/libiconv.a.
  *** I have the capability to make that library automatically link in when
  *** you link to this library.  But I can only do this if you have a
  *** shared version of the library, which you do not appear to have
  *** because the file extensions .a of this argument makes me believe
  *** that it is just a static archive that I should not use here.
  libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries

     Same warning in opcodes and in ibctf.

I ignored those, because they don't prevent the build, but maybe
libtool acted as if --enable-shared was specified, without me saying
so?

Re: Two observations using GDB 13 snapshot

[Hannes Domani]

 Am Samstag, 7. Januar 2023, 17:10:33 MEZ hat Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> Folgendes geschrieben:

> > From: Andreas Schwab <schwab@linux-m68k.org>
> > Cc: gdb-patches@sourceware.org
> > Date: Sat, 07 Jan 2023 16:40:15 +0100
> >
> > On Jan 07 2023, Eli Zaretskii wrote:
> >
> > >> From: Andreas Schwab <schwab@linux-m68k.org>
> > >> Cc: gdb-patches@sourceware.org
> > >> Date: Sat, 07 Jan 2023 15:40:01 +0100
> > >>
> > >> On Jan 07 2023, Eli Zaretskii wrote:
> > >>
> > >> > So the problem is that we are now using libtool, and that causes the
> > >> > GDB executable to be in a directory different from where gdb-gdb.gdb
> > >> > is kept.
> > >>
> > >> That does not happen for me.  Did you configure with --enable-shared?
> > >
> > > No.  Why would I need to?
> >
> > Without it, libtool should have no reason to put gdb in .libs.
>
> I see.  Well, here it is.
>
>
> > > GDB is not a library, and doesn't build libraries that need to be
> > > installed, AFAIK.
> >
> > So why does it create the gdb binary in .libs?  It is empty for me.
>
>
> I don't know.  Any libtool experts around here?

Isn't --enable-shared the default?
Anyways, I also had this 'problem', and once I added --disable-shared,
libtool didn't put the real gdb.exe into .libs anymore.

I think this behavior is a bit different for Windows targets, because of this
part in libtool:

      *cygwin* | *mingw* )
        if test "$build_libtool_libs" != yes; then
          wrappers_required=no
        fi
        ;;


Hannes

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> Date: Sat, 7 Jan 2023 16:16:16 +0000 (UTC)
> From: Hannes Domani <ssbssa@yahoo.de>
> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
>  Am Samstag, 7. Januar 2023, 17:10:33 MEZ hat Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> Folgendes geschrieben:
> 
> > > >> That does not happen for me.  Did you configure with --enable-shared?
> > > >
> > > > No.  Why would I need to?
> > >
> > > Without it, libtool should have no reason to put gdb in .libs.
> >
> > I see.  Well, here it is.
> >
> >
> > > > GDB is not a library, and doesn't build libraries that need to be
> > > > installed, AFAIK.
> > >
> > > So why does it create the gdb binary in .libs?  It is empty for me.
> >
> >
> > I don't know.  Any libtool experts around here?
> 
> Isn't --enable-shared the default?

Yes, it is.  I see this in gdb/config.log:

  Target: mingw32
  Configured with: ../src/gcc-9.2.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-static --enable-shared --enable-threads --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-libgomp --disable-libvtv --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --disable-build-format-warnings --prefix=/mingw --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/mingw --with-isl=/mingw --enable-nls --with-pkgversion='MinGW.org GCC Build-2'
  Thread model: win32

So does it mean I should build with --disable-shared?

Anyway, --enable-shared is a legitimate configuration, so if it causes
the GDB executable to be created in .libs/, IMO the build should act
accordingly nad have a copy of gdb-gdb.gdb in that subdirectory.
Right?

> I think this behavior is a bit different for Windows targets, because of this
> part in libtool:
> 
>       *cygwin* | *mingw* )
>         if test "$build_libtool_libs" != yes; then
>           wrappers_required=no
>         fi
>         ;;

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Hannes Domani wrote:

> Isn't --enable-shared the default?

No.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  "gdb-patches@sourceware.org"
>  <gdb-patches@sourceware.org>
> Date: Sat, 07 Jan 2023 18:39:57 +0100
> 
> On Jan 07 2023, Hannes Domani wrote:
> 
> > Isn't --enable-shared the default?
> 
> No.

gdb/libtool thinks shared libraries should be built:

  # Whether or not to build shared libraries.
  build_libtool_libs=yes

Where does it get that idea?

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  "gdb-patches@sourceware.org"
>>  <gdb-patches@sourceware.org>
>> Date: Sat, 07 Jan 2023 18:39:57 +0100
>> 
>> On Jan 07 2023, Hannes Domani wrote:
>> 
>> > Isn't --enable-shared the default?
>> 
>> No.
>
> gdb/libtool thinks shared libraries should be built:

bfd/libtool and opcodes/libtool don't.

As you already discovered, gdb/libtool is not used for building
libraries at all.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Hannes Domani]

 Am Samstag, 7. Januar 2023, 19:08:23 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:

> > From: Andreas Schwab <schwab@linux-m68k.org>
>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  "gdb-patches@sourceware.org"
> >  <gdb-patches@sourceware.org>
> > Date: Sat, 07 Jan 2023 18:39:57 +0100
> >
> > On Jan 07 2023, Hannes Domani wrote:
> >
> > > Isn't --enable-shared the default?
> >
> > No.

gdb/configure --help says it is:

  --enable-shared[=PKGS]  build shared libraries [default=yes]
  --enable-static[=PKGS]  build static libraries [default=yes]


> gdb/libtool thinks shared libraries should be built:
>
>   # Whether or not to build shared libraries.
>   build_libtool_libs=yes
>
> Where does it get that idea?

From gdb/configure:

# Whether or not to build shared libraries.
build_libtool_libs=$enable_shared


Hannes

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: ssbssa@yahoo.de,  gdb-patches@sourceware.org
> Date: Sat, 07 Jan 2023 19:26:57 +0100
> 
> On Jan 07 2023, Eli Zaretskii wrote:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  "gdb-patches@sourceware.org"
> >>  <gdb-patches@sourceware.org>
> >> Date: Sat, 07 Jan 2023 18:39:57 +0100
> >> 
> >> On Jan 07 2023, Hannes Domani wrote:
> >> 
> >> > Isn't --enable-shared the default?
> >> 
> >> No.
> >
> > gdb/libtool thinks shared libraries should be built:
> 
> bfd/libtool and opcodes/libtool don't.

But the issue at hand is about what happens in gdb/, not in bfd or
opcodes.

> As you already discovered, gdb/libtool is not used for building
> libraries at all.

So you are saying it's a bug in gdb/configure?

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Hannes Domani wrote:

>  Am Samstag, 7. Januar 2023, 19:08:23 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:
>
>> > From: Andreas Schwab <schwab@linux-m68k.org>
>>
>> > Cc: Eli Zaretskii <eliz@gnu.org>,  "gdb-patches@sourceware.org"
>> >  <gdb-patches@sourceware.org>
>> > Date: Sat, 07 Jan 2023 18:39:57 +0100
>> >
>> > On Jan 07 2023, Hannes Domani wrote:
>> >
>> > > Isn't --enable-shared the default?
>> >
>> > No.
>
> gdb/configure --help says it is:
>
>   --enable-shared[=PKGS]  build shared libraries [default=yes]
>   --enable-static[=PKGS]  build static libraries [default=yes]

This is irrelevant for the problem at hand, sind the gdb subdir does not
build any libraries.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Andreas Schwab]

On Jan 07 2023, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: ssbssa@yahoo.de,  gdb-patches@sourceware.org
>> Date: Sat, 07 Jan 2023 19:26:57 +0100
>> 
>> On Jan 07 2023, Eli Zaretskii wrote:
>> 
>> >> From: Andreas Schwab <schwab@linux-m68k.org>
>> >> Cc: Eli Zaretskii <eliz@gnu.org>,  "gdb-patches@sourceware.org"
>> >>  <gdb-patches@sourceware.org>
>> >> Date: Sat, 07 Jan 2023 18:39:57 +0100
>> >> 
>> >> On Jan 07 2023, Hannes Domani wrote:
>> >> 
>> >> > Isn't --enable-shared the default?
>> >> 
>> >> No.
>> >
>> > gdb/libtool thinks shared libraries should be built:
>> 
>> bfd/libtool and opcodes/libtool don't.
>
> But the issue at hand is about what happens in gdb/, not in bfd or
> opcodes.

Only bfd and opcodes build possibly shared libraries, and only that will
have an affect on the necessity to build a gdb libtool wrapper.

>> As you already discovered, gdb/libtool is not used for building
>> libraries at all.
>
> So you are saying it's a bug in gdb/configure?

No.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Two observations using GDB 13 snapshot

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: ssbssa@yahoo.de,  gdb-patches@sourceware.org
> Date: Sat, 07 Jan 2023 20:26:14 +0100
> 
> On Jan 07 2023, Eli Zaretskii wrote:
> 
> >> >> > Isn't --enable-shared the default?
> >> >> 
> >> >> No.
> >> >
> >> > gdb/libtool thinks shared libraries should be built:
> >> 
> >> bfd/libtool and opcodes/libtool don't.
> >
> > But the issue at hand is about what happens in gdb/, not in bfd or
> > opcodes.
> 
> Only bfd and opcodes build possibly shared libraries, and only that will
> have an affect on the necessity to build a gdb libtool wrapper.
> 
> >> As you already discovered, gdb/libtool is not used for building
> >> libraries at all.
> >
> > So you are saying it's a bug in gdb/configure?
> 
> No.

Then I'm afraid I don't understand what you are saying.