aboutsummaryrefslogtreecommitdiff
path: root/gdb/rust-lang.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2023-01-30 15:02:48 -0500
committerSimon Marchi <simon.marchi@polymtl.ca>2023-02-08 16:31:30 -0500
commit6d3717d4c412db52b33fa53f0ea9fc52f3d0aadc (patch)
tree0a829ee65e92084a2bc34ac19246fd91bedb1d56 /gdb/rust-lang.c
parentdcee6fb39812ace0df59b8d0dd43cd41d2f02e54 (diff)
downloadbinutils-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