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.

1 files changed, 2 insertions, 3 deletions

diff --git a/gdb/python/py-type.c b/gdb/python/py-type.c
index 0e772ad44b4..7cfc8d16233 100644
--- a/gdb/python/py-type.c
+++ b/gdb/python/py-type.c
@@ -1123,7 +1123,7 @@ save_objfile_types (struct objfile *objfile, void *datum)
      operating on.  */
   gdbpy_enter enter_py (objfile->arch ());
 
-  htab_up copied_types = create_copied_types_hash (objfile);
+  htab_up copied_types = create_copied_types_hash ();
 
   while (obj)
     {
@@ -1131,8 +1131,7 @@ save_objfile_types (struct objfile *objfile, void *datum)
 
       htab_empty (copied_types.get ());
 
-      obj->type = copy_type_recursive (objfile, obj->type,
-				       copied_types.get ());
+      obj->type = copy_type_recursive (obj->type, copied_types.get ());
 
       obj->next = NULL;
       obj->prev = NULL;