FreeChainXenon/binutils-gdb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Change allocation of type-copying hash table

Browse source 
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.
This commit is contained in:
Tom Tromey 2022-05-24 15:17:19 -06:00
parent b382c16682
commit bde539c2f9
6 changed files with 27 additions and 42 deletions
Download patch file Download diff file Expand all files Collapse all files

5
gdb/python/py-type.c
View file

@ -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;