Re: ARM and virtual/raw registers

[Andrew Cagney <ac131313 at cygnus dot com>]

>> 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).

(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?

> 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.

For instance, the SHcompact PC (I'm going from memory) is constructed 
from two SHmedia registers.  This is implemented by having 
register_{read,write} scatter/gather the relvant value.  Other SHcompact 
registers are sub registers of SHmedia and they are implemented using 
similar techniques.

When it comes to a frame, a custom get_saved_register() handles the 
related problem of SHmedia X SHcompact frame vs request for SHmedia X 
SHcompact register from the next outer frame (I suspect with a few 
lingering edge cases :-).

Andrew