This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
Since GDB now requires C++17, we don't need the internally maintained
gdb::optional implementation. This patch does the following replacing:
- gdb::optional -> std::optional
- gdb::in_place -> std::in_place
- #include "gdbsupport/gdb_optional.h" -> #include <optional>
This change has mostly been done automatically. One exception is
gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
already lives in the gdb namespace.
Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
After DWARF has been scanned, the cooked index code does a
"finalization" step in a worker thread. This step combines all the
index entries into a single master list, canonicalizes C++ names, and
splits Ada names to synthesize package names.
While this step is run in the background, gdb will wait for the
results in some situations, and it turns out that this step can be
slow. This is PR symtab/29105.
This can be sped up by parallelizing, at a small memory cost. Now
each index is finalized on its own, in a worker thread. The cost
comes from name canonicalization: if a given non-canonical name is
referred to by multiple indices, there will be N canonical copies (one
per index) rather than just one.
This requires changing the users of the index to iterate over multiple
results. However, this is easily done by introducing a new "chained
range" class.
When run on gdb itself, the memory cost seems rather low -- on my
current machine, "maint space 1" reports no change due to the patch.
For performance testing, using "maint time 1" and "file" will not show
correct results. That approach measures "time to next prompt", but
because the patch only affects background work, this shouldn't (and
doesn't) change. Instead, a simple way to make gdb wait for the
results is to set a breakpoint.
Before:
$ /bin/time -f%e ~/gdb/install/bin/gdb -nx -q -batch \
-ex 'break main' /tmp/gdb
Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
2.00
After:
$ /bin/time -f%e ./gdb/gdb -nx -q -batch \
-ex 'break main' /tmp/gdb
Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
0.65
Regression tested on x86-64 Fedora 34.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
