This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Available registers as a target property


On Thu, 2005-05-19 at 02:00, Daniel Jacobowitz wrote:
> On Wed, May 18, 2005 at 10:28:35AM +0100, Richard Earnshaw wrote:
> > On Tue, 2005-05-17 at 20:32, Daniel Jacobowitz wrote:
> > 
> > >   /* If this flag is set, GDB should save and restore this register
> > >      around calls to an inferior function.  */
> > >   int save_restore;
> > 
> > Why would the target care about this?  It seems to be more a property of
> > an ABI than the target.  
> > 
> > In the (IMO) unlikely case that we really want to keep this, I think it
> > should have a 'not-my-responsibility-to-decide' setting.
> 
> This isn't the conventional callee-saved vs. caller-saved decision. GDB
> needs to handle bogus functions so it should save/restore all "normal"
> registers, but there may be some registers in a system for which this
> behavior is inappropriate.  Perhaps there's a better name for this if I
> invert the meaning... For instance, a debugger should probably not muck
> with cp15 registers across a function call, even if they're not marked
> readonly, to allow the user to modify them explicitly.
> 
> I'm trying to express the concept of save_reggroup/restore_reggroup for
> target specified registers.  Have you got another idea of how to do it?
> Maybe it's not necessary after all?

Ah!  Light dawns.

Hmm, I've not thought this through in detail.  Perhaps we should define
access/protection classes that a register belongs to.  Something along
the lines of

User		- normal user-space registers
Control		- accessible by users, but generally stateful or volatile 
System		- protected to system mode access only
Sys-ctrl	- Accessible by system, but generally stateful

A parallel attribute might describe whether or not a register can be
written, or whether it is purely for information.

Examples (for ARM) for each of the above classess would be

user		- r0-r15
Control		- VFP FPSCR
System 		- r8_fiq, etc
Sys-ctrl	- cp15

This might be overkill for much of GDB's needs, but in some cases it
might still not be enough.  For example, the CPSR has some bits which
are User, and some that are User/read-only, but system/read-write.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]