Re: ARM and virtual/raw registers

[Richard Earnshaw <rearnsha 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.