Re: [PATCH v3 1/2] gdb: dwarf2 generic implementation for caching function data

[Luis Machado <luis.machado@arm.com>]

On 1/20/23 17:28, Simon Marchi wrote:
> 
>> I suppose a generic cache might be useful in the long run, but it
>> would have an impact on other code paths and I'm not comfortable of
>> doing this major change now. Doing this change would imply that almost
>> everything related to unwinding is impacted in one way or another and
>> I suppose we would need to test that. With the solution I proposed,
>> only Arm Cortex would be impacted and the scope for testing would be
>> rather small.
> 
> I understand the feeling.  It's impossible to test every change on every
> configuration.  We do our best to understand the code and how the change
> will impact different configurations, but we also have to accept a
> certain level of risk that we will break something, otherwise we will
> never change / improve anything.  More eyes on the code, more people
> testing regularly with different configurations and more configurations
> on the Buildbot can help mitigate that.
> 
>> I'm also aiming to resolve this for GDB13, so doing this major change
>> is a bit late in the sprint, right?
> 
> Indeed.  Then I think it's fine to introduce what you have, and then we
> could replace it with a more general solution later.
> 
>> If you have a better idea on how to cache everything, like in your 3
>> ideas above, please don't hesitate do share the implementation. :)
> 
> I imagine something simple.  A hash table in frame_info or somewhere
> else, where frame_unwind_register_value would put values returned by
> `next_frame->unwind->prev_register`, which would be returned directly on
> subsequent calls.  This makes the assumption that a given frame info
> object has the same unwinder throughout its lifetime, and that it will
> return the same register value throughout its lifetime.  I don't know of
> any situation where that is not true.
> 
> To keep the allocation / deallocation cost down, the hash tables could
> be allocated on the frame obstack.

Maybe not a solution for now, but can't we use something like the trad-frame structs to cache
values/locations of registers for a given frame?