Re: ARM and virtual/raw registers

[Andrew Cagney <ac131313@cygnus.com>]

> Even consider making everything a pseudo so that you know exactly what 
>> you have at any stage.
>> 
> 
> 
> Hmm, I think this is effectively what I have. See the code below (which is 
> very much a work-in-progress..., so don't even expect it to compile ;-)

Even more ruthless.  Try a register layout of:

--
raw normal r0..r15
raw someothers
raw floats
raw bank r0..r15
raw still more
--
pseudo r0..r15
	mapped onto either normal or banked
pseudo floats
	mapped onto floats
and so on, for instance, explict register names to identify normal and 
banked r0.
--

which completly separates the raw and pseudo registers.  The function 
register_name() becomes:

	if regnum < NUM_REGS
		return "";
	else
		return yourtable[regnum - NUM_REGS];

In an ideal world, I'd be changing register_{read,write} to take a 
``struct pseudoreg *'' and regcache_{read,write} to take a ``struct 
rawreg *''.  That way it would be clear what is going on.  I can but 
dream! I'm still trying to bury registers[] -)

>> > I can make my arm_register_read function correctly remap the register 
>> > numbers, but then I run into the problem that REGISTER_RAW_SIZE is used 
>> > both above and below the regcache.
> 
>> 
>> I don't understand why this is a problem.  I think a register (pseudo or 
>> raw) should have only one size (c.f. my register_size() patch).
> 
> 
>  However, in this situation, 
> pseudo_rengo("r0") != regcache_regno("r0"), yet we effectively have
> 
> REGSITER_RAW_SIZE (pseudo_regno ("r0")) 
> and
> REGISTER_RAW_SIZE (regcache_regno ("r0"))

Sorry, I still don't understand.  Given pseudo-registers, the name of 
the function ``register_raw_size'' is definitly overloaded.  However, 
per the patch very recently committed, the norm should now be:
register_raw_size() == register_virtual_size() == TYPE_LENGTH 
(register_virtual_type()) (which makes them all badly named :-)

> ! /* We have more registers than the disassembler as gdb can print the
> !    value of special registers as well.  It can also display the
> !    contents of banked registers if these are available from the
> !    inferior.
> ! 
> !    Depending on the architecture, ARM processors have up to 31 integer
> !    registers, but these are banked so that only 16 are visible at any
> !    one time.  The layout of the table is complicated by the fact that
> !    the ordering must match that used by the compiler to generate
> !    stabs/dwarf entries, so we put the banked registers first, even
> !    though we implement some of them as pseudos (mapping onto the
> !    correct bank entry for the current mode).  A debug record entry may
> !    contain:
> ! 
> !    0-15 for the integer registers r0-r15,
> !    16-23 for the FPA registers f0-f7,
> !    32-63 for the VFP registers s0-s31.

This restriction doesn't exist.

Your architecture has complete control over how debug register numbers 
are represented internally.  For instance, STABS_REG_TO_REGNUM() can be 
used to completly map the above numbers onto pseudo-registers.

Again, in an ideal world, I'd try to change these functions to return a 
``struct pseudoreg *''.  That would make it clear which side of the 
fence they sit on :-)

> !    Which leaves a gap of 8 registers in the numbering space: we put
> !    the cpsr, spsr (x5), fpsr and fpcr registers in this space, though
> !    not all of these will always be available.  None of these registers
> !    will have debug table entries. [XXX-rwe 20020511 At least, I don't
> !    think so].
> ! 
> !    The general register names are overwritten by whatever is being
> !    used by the disassembler at the moment.  We also adjust the case of
> !    cpsr and fps.  
> ! 
> !    Note, the ordering of registers in the regcache is entirely
> !    different, since we don't want the pseudo registers in that.  The
> !    mapping tables follow.  */

(I think I remember what you wanted me to document ....)

enjoy,
Andrew