gdb: call frame unwinders' dealloc_cache methods through destroying the frame cache
authorSimon Marchi <simon.marchi@efficios.com>
Mon, 30 Jan 2023 20:02:48 +0000 (15:02 -0500)
committerSimon Marchi <simon.marchi@polymtl.ca>
Wed, 8 Feb 2023 21:31:30 +0000 (16:31 -0500)
commit6d3717d4c412db52b33fa53f0ea9fc52f3d0aadc
tree0a829ee65e92084a2bc34ac19246fd91bedb1d56
parentdcee6fb39812ace0df59b8d0dd43cd41d2f02e54
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
gdb/frame.c