Re: Saving/restoring the entire register set

[Andrew Cagney <ac131313 at cygnus dot com>]

Interesting timeing,

> The current implementation of generic_{push,pop}_dummy_frame use 
> 
> 	{read,write}_register_bytes (0, addr, REGISTER_BYTES)
> 
> to save/restore the entire regset.  

Interesting timing, see:
http://sources.redhat.com/ml/gdb/2002-05/msg00116.html

> This is causing a problem for me with the new pseudo/raw register
> separation that I'm trying to create because write_register_bytes calls
> write_register_gen which calls arm_register_write and then aborts because
> we are trying to directly update a raw register rather than a pseudo.

Hmm, {read,write} register bytes can call the legacy {read,write} 
register gen.  Those functions provide the behavour the {read,write} 
bytes functions rely on.  I guess I didn't notice this when adding 
regcache_read().

For the record (per numerious change requests) {read,write} register 
bytes need to be snuffed out.

> While the dummy frame code does seem to be doing something sensible, doing
> it this way is somewhat of a pain, because I really want to fault out
> attempts to directly poke into the raw registers (I've already tracked down
> two or three bugs this way).
> 
> For this special case of saving/restoring the entire register bank, I wonder if a more suitable interface might be to have calls such as
> 
>   struct regcache *regcache_alloc (); /* Allocate a new regcache structure */
>   regcache_save (regcache);	      /* Copy current registers into it */
>   regcache_restore (regcache);	      /* Restore registers from it */
>   regcache_free (regcache);	      /* Release it */
> 
> which would directly perform the precise operations that are required.
> 
> These routines could then directly use the legacy_{read,write}_register_gen
> interface to fill/restore a copy of the structure. 

[Since someone will likely now look at that post]

--

regbuf.[hc] adds just a register buffer.  It should be a raw register 
only buffer except .... (sigh).  The objective is purely to replace 
registers[] with an object.

If you look through the patch, you'll notice that I also modify 
functions such as extract_struct_value_adress and value_being_returned 
to take a ``struct regbuf'' instead of the raw registers array.  That 
part is strictly a sideways transformation - I'm not trying to fix anything.

--

I think, eventually, there will be a ``struct state'' object that makes 
available either the live (call through to the target register/memory 
code) or saved (just consult the local cache) state of the target.  The 
saved state could include both saved registers and memory.  This is why 
a ``struct regcache'' wouldn't do the trick.  I've seen one target that 
needs to restore memory to correctly recover from a call dummy 
(fortunatly no one has tried to integrate this into current gdb).

Functions such as extract_struct_value_address would take this object 
instead of registers[]/regbuf.  That code could then call register 
{read,write} (which also takes a ``struct state'') to read/write values.

--

At present GDB saves and restores all the raw registers. This is 
overkill.  After an inferior function call, you probably don't want to 
restore all the registers (in fact you probably don't want to save them 
- forcing them to be fetched from the target).  Hence, architecture 
methods like:

	raw_register_save_p()
	raw_register_restore_p()

will be needed.

--

thoughts,
Andrew