[gdb/symtab] Add call_site_eq and call_site_hash
authorTom de Vries <tdevries@suse.de>
Mon, 4 Oct 2021 16:16:40 +0000 (18:16 +0200)
committerTom de Vries <tdevries@suse.de>
Mon, 4 Oct 2021 16:16:40 +0000 (18:16 +0200)
commit0dd8295da24ae58c1e808b906b7c0aafea22a259
treefd64ad6c5a426a23828288c537100bbd561ca8eb
parentabe19f1119ef3d33acd9c8699ebeb110feed55d8
[gdb/symtab] Add call_site_eq and call_site_hash

In commit b4c919f7525 "[gdb/symtab] Fix htab_find_slot call in
read_call_site_scope" , I removed the comment:
...
It must be the first field as we overload core_addr_hash and core_addr_eq for
it.
...
for field pc of struct call_site.

However, this was not tested, and when indeed moving field pc to the second
location, we run into a testsuite failure in gdb.trace/entry-values.exp.

This is caused by core_addr_eq (the eq_f function for the htab) being
called with a pointer to the pc field (as passed into htab_find_slot) and a
pointer to a hash table element.  Now that pc is no longer the first field,
the pointer to hash table element no longer points to the pc field.

This could be fixed by simply reinstating the comment, but we're trying to
get rid of this kind of tricks that make refactoring more difficult.

Instead, fix this by:
- reverting commit b4c919f7525, apart from the comment removal, such that
  we're passing a pointer to element to htab_find_slot
- updating the htab_find_slot call in compunit_symtab::find_call_site
  in a similar manner
- adding a call_site_eq and call_site_hash, and using these in the hash table
  instead of core_addr_eq and core_addr_hash.

Tested on x86_64-linux, both with and without a trigger patch that moves pc to
the second location in struct call_site.
gdb/dwarf2/read.c
gdb/gdbtypes.h
gdb/symtab.c