Saving/restoring the entire register set

Saving/restoring the entire register set

[Richard Earnshaw]

The current implementation of generic_{push,pop}_dummy_frame use 

	{read,write}_register_bytes (0, addr, REGISTER_BYTES)

to save/restore the entire regset.  

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.

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. 

R.

Re: Saving/restoring the entire register set

[Jason R Thorpe]

On Tue, May 14, 2002 at 04:17:37PM +0100, Richard Earnshaw wrote:

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

Sounds perfectly sensible to me.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: Saving/restoring the entire register set

[Andrew Cagney]

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

Re: Saving/restoring the entire register set

[Richard Earnshaw]

> 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

Hmm, the patch in that file is missing the contents of regbuf.[ch], so I 
can't try it, even if I wanted :-(

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

Missing out the intervening layers would probably solve the problem in 
this case.

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

Yes please...


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

How about creating a "regbuf" branch where we can play with these ideas a 
little more without the risk of destabilizing everything?  That way we 
don't keep having to wait a week for each change to go in.

R.

Re: Saving/restoring the entire register set

[Andrew Cagney]

> Hmm, the patch in that file is missing the contents of regbuf.[ch], so I 
> can't try it, even if I wanted :-(

Oops.  Watch for a reply with everything


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

More importantly, that one is ``moving forward''.

> How about creating a "regbuf" branch where we can play with these ideas a 
> little more without the risk of destabilizing everything?  That way we 
> don't keep having to wait a week for each change to go in.

Hmm, ....!

Andrew