aboutsummaryrefslogtreecommitdiff
path: root/gdb/Makefile.in
diff options
context:
space:
mode:
authorTom Tromey <tom@tromey.com>2022-05-24 15:17:19 -0600
committerTom Tromey <tom@tromey.com>2022-07-28 14:16:50 -0600
commitbde539c2f9e19271d6d6c740f875b4129e03eba3 (patch)
tree0e92a4f02b0411afcf14297bc6c200c69ef62aee /gdb/Makefile.in
parentb382c16682acc33d2e81e5604c9dbd408be376d2 (diff)
downloadgdb-bde539c2f9e19271d6d6c740f875b4129e03eba3.zip
gdb-bde539c2f9e19271d6d6c740f875b4129e03eba3.tar.gz
gdb-bde539c2f9e19271d6d6c740f875b4129e03eba3.tar.bz2
Change allocation of type-copying hash table
When an objfile is destroyed, types that are still in use and allocated on that objfile are copied. A temporary hash map is created during this process, and it is allocated on the destroyed objfile's obstack -- which normally is fine, as that is going to be destroyed shortly anyway. However, this approach requires that the objfile be passed to registry destruction, and this won't be possible in the rewritten registry. This patch changes the copied type hash table to simply use the heap instead. It also removes the 'objfile' parameter from copy_type_recursive, to make this all more clear. This patch also fixes an apparent bug in copy_type_recursive. Previously it was copying the dynamic property list to the dying objfile's obstack: - = copy_dynamic_prop_list (&objfile->objfile_obstack, However I think this is incorrect -- that obstack is about to be destroyed.
Diffstat (limited to 'gdb/Makefile.in')
0 files changed, 0 insertions, 0 deletions