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: Fri, 10 May 2002 11:44:48 +0100
- Subject: Re: ARM and virtual/raw registers
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
(notice - convert-to-virtual free zone).
>
> (and how I'm quietly eliminating it :-)
>
:-)
> > 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).
>
> In APCS-32 mode, is there any overlap of information between it and the PC?
No, the bits in the PC that were used for the CPSR are now used for
addressing the full 4Mb of memory.
However, I agree that this should somehow be done with the pseudo
mechanism if the physical register doesn't exist.
>
> > 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.
>
> Yes, I agree that raw<->virtual is wrong; but no, it shouldn't be pushed
> down below the target.
>
> > 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.
>
> Have a look at the SH5 patch. I think this gets it right.
>
> The first cut at all this had the target using supply_register() to fill
> in missing values in from below the cache - turns out this makes
> coherency hard. The current revision uses register_{read,write} above
> the cache to do this, thus eliminating redundant information in the cache.
>
> For the SH5, the raw register cache contains SHmedia (32/64 bit?)
> registers (as that is what the raw hardware has). Pseudo-registers, and
> register_{read,write} are then used to map SHcompact (16/32?) registers
> onto the corresponding raw registers.
OK, I'll buy the argument that the cache should contain exactly the
physical registers and nothing else (ie no pseudos). That is, there is a
one-one mapping between the registers in the cache and the registers in
the machine. The issue is what the format of those registers in the cache
should be. My feeling is that they should be normalized (I deliberately
use a different word from virtualized), so that regardless of the access
mechanism used in the target vector -- again note, not the gdbarch
vector-- (eg, does the protocol transfer four words, or only three), the
format of the values in the cache are the same. Now obviously for this to
work, then there must exist mapping functions f() and f'() that convert
between the two formats with no loss of information for the useful domain
of the register. With the above constraints, I can't see how that would
lead to any coherency issues.
Now, ideally, this normalized format would be the same as the virtualized
format (so that no further conversion was needed), and that would also
match the memory format used by a register save to the stack frame.
However, on the ARM, we can't really predict what that format will be --
it could well depend on the instructions used to generate the frame (STFE
or SFM). Further, we probably also need to know the type of FPE/FPA in
use by the target to understand that format, and that can only be done by
interrogating the FPSR (floating point status register). So, I think we
also need additional conversion routines, say g() and g'() that convert to
and from memory format -- we may even need multiple such functions, since
if we are reading from a memory location created with stfe we may need a
different conversion from when a memory location was created with sfm.
These conversions ARE part of the arch vector, but for most targets will
be identity operations.
Now obviously, in order to do all this correctly the stack-frame groveller
will have to record the information as it unwinds the stack in some
private data; but creating this information is part of the stack-unwinding
process.
R.