This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: ARM and virtual/raw registers
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Richard dot Earnshaw at arm dot com, gdb at sources dot redhat dot com
- Date: Thu, 09 May 2002 18:00:18 +0100
- Subject: Re: ARM and virtual/raw registers
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot 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.