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.
I hesitated between putting the file in the dwarf2 directory (as
gdb/dwarf2/call-site.h) or in the common directory (as gdb/call-site.h).
The concept of call site is not DWARF-specific, another debug info
reader could provide this information. But as it is, the implementation
is a bit DWARF-specific, as one form it can take is a DWARF expression
and parameters can be defined using a DWARF register number. So I ended up
choosing to put it under dwarf2/. If another debug info reader ever
wants to provide call site information, we can introduce a layer of
abstraction between the "common" call site and the "dwarf2" call site.
The copyright start year comes from the date `struct call_site` was
introduced.
Change-Id: I1cd84aa581fbbf729edc91b20f7d7a6e0377014d
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
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.
This patch started when I noticed that the unordered_set include
wasn't needed in abbrev-cache.h. (That was probably leftover from
some earlier implementation of the class.) Then, I noticed that the
class itself was under-commented. This patch fixes both issues.
The replacement for the DWARF psymbol reader works in a somewhat
different way. The current reader reads and stores all the DIEs that
might be interesting. Then, if it is missing a DIE, it re-scans the
CU and reads them all. This approach is used for both intra- and
inter-CU references.
I instrumented the partial DIE hash to see how frequently it was used:
[ 0] -> 1538165
[ 1] -> 4912
[ 2] -> 96102
[ 3] -> 175
[ 4] -> 244
That is, most DIEs are never used, and some are looked up twice -- but
this is just an artifact of the implementation of
partial_die_info::fixup, which may do two lookups.
Based on this, the new implementation doesn't try to store any DIEs,
but instead just re-scans them on demand. In order to do this,
though, it is convenient to have a cache of DWARF abbrevs. This way,
if a second CU is needed to resolve an inter-CU reference, the abbrevs
for that CU need only be computed a single time.
