Change allocation of type-copying hash table
authorTom Tromey <tom@tromey.com>
Tue, 24 May 2022 21:17:19 +0000 (15:17 -0600)
committerTom Tromey <tom@tromey.com>
Thu, 28 Jul 2022 20:16:50 +0000 (14:16 -0600)
commitbde539c2f9e19271d6d6c740f875b4129e03eba3
tree0e92a4f02b0411afcf14297bc6c200c69ef62aee
parentb382c16682acc33d2e81e5604c9dbd408be376d2
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.
gdb/compile/compile-object-run.c
gdb/gdbtypes.c
gdb/gdbtypes.h
gdb/guile/scm-type.c
gdb/python/py-type.c
gdb/value.c