diff options
author | Simon Marchi <simon.marchi@efficios.com> | 2023-01-30 15:02:48 -0500 |
---|---|---|
committer | Simon Marchi <simon.marchi@polymtl.ca> | 2023-02-08 16:31:30 -0500 |
commit | 6d3717d4c412db52b33fa53f0ea9fc52f3d0aadc (patch) | |
tree | 0a829ee65e92084a2bc34ac19246fd91bedb1d56 /gdb/rust-lang.c | |
parent | dcee6fb39812ace0df59b8d0dd43cd41d2f02e54 (diff) | |
download | binutils-6d3717d4c412db52b33fa53f0ea9fc52f3d0aadc.zip binutils-6d3717d4c412db52b33fa53f0ea9fc52f3d0aadc.tar.gz binutils-6d3717d4c412db52b33fa53f0ea9fc52f3d0aadc.tar.bz2 |
gdb: call frame unwinders' dealloc_cache methods through destroying the frame cache
Currently, some frame resources are deallocated by iterating on the
frame chain (starting from the sentinel), calling dealloc_cache. The
problem is that user-created frames are not part of that chain, so we
never call dealloc_cache for them.
I propose to make it so the dealloc_cache callbacks are called when the
frames are removed from the frame_stash hash table, by registering a
deletion function to the hash table. This happens when
frame_stash_invalidate is called by reinit_frame_cache. This way, all
frames registered in the cache will get their unwinder's dealloc_cache
callbacks called.
Note that at the moment, the sentinel frames are not registered in the
cache, so we won't call dealloc_cache for them. However, it's just a
theoritical problem, because the sentinel frame unwinder does not
provide this callback. Also, a subsequent patch will change things so
that sentinel frames are registered to the cache.
I moved the obstack_free / obstack_init pair below the
frame_stash_invalidate call in reinit_frame_cache, because I assumed
that some dealloc_cache would need to access some data on that obstack,
so it would be better to free it after clearing the hash table.
Change-Id: If4f9b38266b458c4e2f7eb43e933090177c22190
Diffstat (limited to 'gdb/rust-lang.c')
0 files changed, 0 insertions, 0 deletions