aboutsummaryrefslogtreecommitdiff
path: root/gdb/python
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2025-02-25 15:54:55 -0500
committerSimon Marchi <simon.marchi@polymtl.ca>2025-02-25 22:43:49 -0500
commit2b5a48b6a9dddd6a2f7d189f3fa906adcab51b92 (patch)
tree955398666312b65fd314ff8c7808bfece1bebabd /gdb/python
parentfb3511fc4765a8bbc837dc798c683d46a0d460cb (diff)
downloadbinutils-2b5a48b6a9dddd6a2f7d189f3fa906adcab51b92.zip
binutils-2b5a48b6a9dddd6a2f7d189f3fa906adcab51b92.tar.gz
binutils-2b5a48b6a9dddd6a2f7d189f3fa906adcab51b92.tar.bz2
gdb/dwarf: convert dwarf2_per_bfd::signatured_types to a gdb::unordered_set
I'd like to add these asserts in dwarf2_per_cu_data's constructor: gdb_assert (per_bfd != nullptr); gdb_assert (section != nullptr); However, these dummy instances of signatured_type, used as hash table lookup keys, are in the way: signatured_type find_sig_entry (nullptr, nullptr, sect_offset {}, sig); This motivated me to convert the dwarf2_per_bfd::signatured_types hash table to a gdb::unordered_set. This allows finding an entry by simply passing the signature (an integer) and removes the need to create dummy signatured_type objects. There is one small unfortunate pessimization: lookup_dwo_signatured_type, for instance, does a lookup by signature to find an existing signatured_type. If not found, it adds a new one by calling add_type_unit. The current code passes down the slot where to put the new element, avoiding an extra hash when inserting the new signatured_type. With the new code, I don't see a way to do that. This is probably negligible, but it bugs me. If we used a map of signature -> signatured_type, I would see a way, but then it would waste space. I see one change in behavior, that is not really important IMO. In read_comp_units_from_section, if duplicate signature type entries are detected, the code prior to this patch overwrites the existing signatured_type in the hash table with the new one. With this patch, the existing signatured_type is kept: the call to emplace does not insert the value if an existing equal value exists. Other than that, no behavior change expected. Change-Id: I0bef1b49cc63dbdf4e32fa9d4ea37f83025efc3e Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/python')
0 files changed, 0 insertions, 0 deletions