This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Saving/restoring the entire register set
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: thorpej at wasabisystems dot com, Richard dot Earnshaw at arm dot com, gdb at sources dot redhat dot com
- Date: Wed, 15 May 2002 11:08:15 +0100
- Subject: Re: Saving/restoring the entire register set
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm 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
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.