Re: Saving/restoring the entire register set

[Richard Earnshaw <rearnsha@arm.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

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.