Re: [PATCH] Replace regbuf with regcache in record-full.c

[Alan Hayward <Alan.Hayward@arm.com>]

>> 
>>> 
>>> As I understand it, the cooked registers exist because on some architectures
>>> extra state needs saving in the cooked registers (code comment: "some
>>> architectures
>>> need to save/restore `cooked registers that live in memory.”).
>>> 
>>> Therefore the cooked register state needs to be a property of detached
>>> and not of
>>> readonly.
>>> 
>> 
>> m_registers and m_register_status are fields of detached regcache, we
>> can definitely save cooked register state in detached regcache.
>> 
>>> 
>>> A different issue is that we treat save/restore differently.
>>> In your code one of the recaches has to be both read-only (checking
>>> via gdb_assert) and detached.
>>> In my code the check is that the regcache is detached or
>>> not. Read-only is not relevant.
>> 
>> It is read-only in my code, but it doesn't have to be.  I don't see any
>> show-stoppers in the design of splitting regcache.  The attributes
>> "detached" and "read-only" are orthogonal in design.  Do you have some
>> comments on the overall design rather than the code details?  I'll
>> rewrite my patches, and post them.  It is unfortunate that it is hard to
>> review the overall design without the code.
> 


I’ve taken a look at implementing the split regcache and have run into an
interesting issue.

frame.c, infcmd.c, infrun.c, jit.c, linux-fork.c, mi/mi-main.c
These files all duplicate the register cache.
In the new patch, this will a create detached_regcache.

These files then access this copied (detached) regcache using:
regcache_cooked_read
gdbarch_pseudo_register_read_value
gdbarch_return_value
regcache_read_pc

It’s easy enough to replace the cooked_read with a raw_collect.

However, the other three are a lot trickier.
They all call out to target functions, (….which call out to other functions…)
which all make multiple calls to cooked_read and raw_read.

The target functions can’t be updated to use raw_collect, because in other case
they will be used with the attached regcache, which will be expecting reads to be
pulled from the target.

Creating duplicate functions (e.g. gdbarch_detached_return_value) would be silly.

The only solution I can see is to create virtual cooked_read and raw_read in
detached_regcache. These functions  just read from the cache instead of
updating from the target.
In this new world, calling cooked_read or raw_read on either a detached_regache
or attached regcache would do the correct thing.

(The function prototypes in all the target files still need updating, but that is a fairly
simple copy/paste.)

Does this approach seem sensible?
If there are no objections, I’ll carry on working the patch using this approach.

I can post a work in progress patch if required (but that might be better to wait until
I have something fully working and split into smaller changes).

Alan.