diff options
author | Tom Tromey <tom@tromey.com> | 2022-05-24 15:17:19 -0600 |
---|---|---|
committer | Tom Tromey <tom@tromey.com> | 2022-07-28 14:16:50 -0600 |
commit | bde539c2f9e19271d6d6c740f875b4129e03eba3 (patch) | |
tree | 0e92a4f02b0411afcf14297bc6c200c69ef62aee /gdb/Makefile.in | |
parent | b382c16682acc33d2e81e5604c9dbd408be376d2 (diff) | |
download | gdb-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