[patch] Add PS_REGNUM.

[patch] Add PS_REGNUM.

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

Hello,

This patch just fills in a gap in the current *_REGNUMs by adding 
PS_REGNUM.  Unlike the others.  This one really does allow -1 as the 
default value.

(FP_REGNUM et.al. require real values as there is code around that, 
unfortunatly, depends on there being a real FP register et.al.  ulgh).

committed,
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1210 bytes --]

2002-04-06  Andrew Cagney  <ac131313@redhat.com>

	* gdbarch.sh (PS_REGNUM): Add.  Document.  Default to -1.
	* gdbarch.c, gdbarch.h: Re-generate.

Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.122
diff -u -r1.122 gdbarch.sh
--- gdbarch.sh	2002/04/06 03:07:59	1.122
+++ gdbarch.sh	2002/04/06 20:17:23
@@ -431,9 +431,16 @@
 # These pseudo-registers may be aliases for other registers,
 # combinations of other registers, or they may be computed by GDB.
 v:2:NUM_PSEUDO_REGS:int:num_pseudo_regs::::0:0::0:::
+
+# GDB's standard (or well known) register numbers.  These can map onto
+# a real register or a pseudo (computed) register or not be defined at
+# all (-1).  FIXME: cagney/2002-04-05: As of the time of writing, only
+# the PS_REGNUM was optional - code still depends on the others (fp,
+# pc, sp) designating registers.
 v:2:SP_REGNUM:int:sp_regnum::::0:-1
 v:2:FP_REGNUM:int:fp_regnum::::0:-1
 v:2:PC_REGNUM:int:pc_regnum::::0:-1
+v:2:PS_REGNUM:int:ps_regnum::::-1:-1::0
 v:2:FP0_REGNUM:int:fp0_regnum::::0:-1::0
 v:2:NPC_REGNUM:int:npc_regnum::::0:-1::0
 v:2:NNPC_REGNUM:int:nnpc_regnum::::0:-1::0

Re: [patch] Add PS_REGNUM.

[Daniel Jacobowitz]

On Sat, Apr 06, 2002 at 03:25:46PM -0500, Andrew Cagney wrote:
> Hello,
> 
> This patch just fills in a gap in the current *_REGNUMs by adding 
> PS_REGNUM.  Unlike the others.  This one really does allow -1 as the 
> default value.
> 
> (FP_REGNUM et.al. require real values as there is code around that, 
> unfortunatly, depends on there being a real FP register et.al.  ulgh).
> 
> committed,
> Andrew

What benefit does this have?  PC_REGNUM I can understand.  Even
SP_REGNUM.  But it's not like PS_REGNUM has any meaning to common
code...


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] Add PS_REGNUM.

[Andrew Cagney]

> On Sat, Apr 06, 2002 at 03:25:46PM -0500, Andrew Cagney wrote:
> 
>> Hello,
>> 
>> This patch just fills in a gap in the current *_REGNUMs by adding 
>> PS_REGNUM.  Unlike the others.  This one really does allow -1 as the 
>> default value.
>> 
>> (FP_REGNUM et.al. require real values as there is code around that, 
>> unfortunatly, depends on there being a real FP register et.al.  ulgh).
>> 
>> committed,
>> Andrew
> 
> 
> What benefit does this have?  PC_REGNUM I can understand.  Even
> SP_REGNUM.  But it's not like PS_REGNUM has any meaning to common
> code...

I think it is the other way round.  PS_REGNUM is the only one being used 
correctly - when >=0, std-regs.c (new file) maps $ps onto a 
hardware/pseudo register.  Cf the GDB manual.

On the other hand FP_REGNUM, PC_REGNUM and SP_REGNUM that are being used 
``incorrectly''(1).  They have no meaning outside of std-regs.c yet are 
used throughout GDB.

enjoy,
Andrew

(1) I'm rewriting history here.  There was a time when the FP_REGNUM was 
both a hardware register and the frame-base.

Re: [patch] Add PS_REGNUM.

[Daniel Jacobowitz]

On Sun, Apr 07, 2002 at 02:54:02PM -0400, Andrew Cagney wrote:
> >On Sat, Apr 06, 2002 at 03:25:46PM -0500, Andrew Cagney wrote:
> >
> >>Hello,
> >>
> >>This patch just fills in a gap in the current *_REGNUMs by adding 
> >>PS_REGNUM.  Unlike the others.  This one really does allow -1 as the 
> >>default value.
> >>
> >>(FP_REGNUM et.al. require real values as there is code around that, 
> >>unfortunatly, depends on there being a real FP register et.al.  ulgh).
> >>
> >>committed,
> >>Andrew
> >
> >
> >What benefit does this have?  PC_REGNUM I can understand.  Even
> >SP_REGNUM.  But it's not like PS_REGNUM has any meaning to common
> >code...
> 
> I think it is the other way round.  PS_REGNUM is the only one being used 
> correctly - when >=0, std-regs.c (new file) maps $ps onto a 
> hardware/pseudo register.  Cf the GDB manual.
> 
> On the other hand FP_REGNUM, PC_REGNUM and SP_REGNUM that are being used 
> ``incorrectly''(1).  They have no meaning outside of std-regs.c yet are 
> used throughout GDB.

So what you're saying is that you added PS_REGNUM so that it could be
used as a standard $ps register name, not for the rest of GDB, right?

I don't really see the point; anyone who wants to look at the processor
status register presumably knows what some of the bits in it mean,
which is entirely architecture dependant.  But caveat implementor :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] Add PS_REGNUM.

[Andrew Cagney]

> I think it is the other way round.  PS_REGNUM is the only one being used 
>> correctly - when >=0, std-regs.c (new file) maps $ps onto a 
>> hardware/pseudo register.  Cf the GDB manual.
>> 
>> On the other hand FP_REGNUM, PC_REGNUM and SP_REGNUM that are being used 
>> ``incorrectly''(1).  They have no meaning outside of std-regs.c yet are 
>> used throughout GDB.
> 
> 
> So what you're saying is that you added PS_REGNUM so that it could be
> used as a standard $ps register name, not for the rest of GDB, right?

Yes.  And that is how FP_REGNUM et.al. should be used ....

> I don't really see the point; anyone who wants to look at the processor
> status register presumably knows what some of the bits in it mean,
> which is entirely architecture dependant.  But caveat implementor :)

Who am I to argue with the documentation :-)

Andrew

Re: [patch] Add PS_REGNUM.

[Daniel Jacobowitz]

On Sun, Apr 07, 2002 at 05:08:41PM -0400, Andrew Cagney wrote:
> >I think it is the other way round.  PS_REGNUM is the only one being used 
> >>correctly - when >=0, std-regs.c (new file) maps $ps onto a 
> >>hardware/pseudo register.  Cf the GDB manual.
> >>
> >>On the other hand FP_REGNUM, PC_REGNUM and SP_REGNUM that are being used 
> >>``incorrectly''(1).  They have no meaning outside of std-regs.c yet are 
> >>used throughout GDB.
> >
> >
> >So what you're saying is that you added PS_REGNUM so that it could be
> >used as a standard $ps register name, not for the rest of GDB, right?
> 
> Yes.  And that is how FP_REGNUM et.al. should be used ....

Completely agree.

> >I don't really see the point; anyone who wants to look at the processor
> >status register presumably knows what some of the bits in it mean,
> >which is entirely architecture dependant.  But caveat implementor :)
> 
> Who am I to argue with the documentation :-)

Didn't know it was there, but now I see it.  So true... :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer