Re: ARM and virtual/raw registers

[Richard Earnshaw <rearnsha@arm.com>]

> 
> > In addition to the above, we also have the case of the CPSR register.  On 
> > old ARM chips (or on non-thumb chips up to armv4), this register is, or 
> > can be mimicked as being, part of the PC.  This suggests to me that the 
> > current decoding shenanigans that are currently hidden in some of the 
> > back-end code should probably be moved into the virtual-raw conversion 
> > layer.  That is, register_convirt_{to,from}_virtual(CPSR) (or whatever 
> > it's really called) should be responsible for the updating of raw-PC or 
> > raw-CPSR as appropriate.
> 
> Hmm, what exactly do you mean by mimicked?  Can the entire register 
> contents be constructed from information found in the other raw/hardware 
> registers?  If that is the case then making it a pseudo-register and 
> using register_{read,write} should do the trick.
> 
> (notice - convert-to-virtual free zone).

In the case where the real register does not exist (arm2, arm3), or when 
the register doesn't exist in the current operating mode (arm6, arm7 -- 
though not arm7tdmi, arm8 and sa1 when running in apcs-26 mode), then the 
CPSR is part of the PC and we mimic its existence within GDB; so yes, in 
that case it is a virtual register.

But when we are running in pure apcs-32 mode, then CPSR is a separate 
register (with additional bits defined).

The more I think about it, the more I think that the raw<->virtual 
translation is in the wrong part of GDB.  Shouldn't this be part of the 
Target interface?  Then conversion to/from virtual format would happen as 
data is passed to/from the inferior, and the rest of GDB would only use 
the virtual format.

As I understand it, this would clean up the MIPS issue entirely -- when 
talking to a target that supplies additional bits for a register, the 
target layer would strip these off/add them back, and the rest of gdb 
wouldn't have to worry about it.

R.