ARM and virtual/raw registers

[Richard Earnshaw]

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

In my view of things, the domain of the result returned by pseudo_regno() 
is
0..Num_pseudos,

and the domain of regcache_regno() is

0..NUM_REGS

But we have cases where the two functions return a different number for 
the same register; more precisely, we might encounter the situation where

pseudo_regno ("int_reg0") == regcache_regno ("float_reg5")

and clearly in this case one of these will give the wrong answer if used 
to call REGISTER_RAW_SIZE().

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

This has nothing to do with the raw and virtual sizes being different, or 
the raw and virtual types being different.

> 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_REGO
> 		return "";
>	else
> 		return yourtable[regnum - NUM_REGS];

Hmm, not quite, I'm trying to bury the regcache even deeper than that...  
It simply does not exist to most of core-gdb, except by calling through 
arm_register_read(), which is the only function that knows how to map a 
regno onto its regcache entry.

R.
R.