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

[Simon Marchi <simark@simark.ca>]

> 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.

Simon