Re: pseudo registers in the regcache

[Richard Earnshaw <rearnsha@arm.com>]

> I think the line-in-sand approach to just banning values in 
> pseudo-registers post register-read is both better and easier

Don't get me wrong, I'm all in favour of tightening up the definitions.  
What frightens me is the length of time that the "legacy" interfaces will 
have to remain (and the rate at which we are growing the number of them).

> 
> Shouldn't be too hard to do this using the tweaked regcache  - that uses 
> regcache->descr->nr_registers instead of NUM_REGS + NUM_PSEUDO_REGS.  In 
> fact [evil laughter :-)] I can think of a few other things that it could 
> disallow:
> 	- holes in the register cache

Hmm, I think this will depend on who "owns" the regcache layout.  If it's 
a property of the "target" vector, then that is reasonable.  If it's a 
property of the tdep code (gdbarch vector), as I think it should be, then 
I don't think it is reasonable.

Forcing the tdep code to modify it's understanding of the regcache layout 
for each possible target sounds like a nightmare.  And since not every 
target can supply all the registers that might exist in an ARM system we 
are bound to be left with holes at times.

My preferred solution would be for tdep code (gdbarch) to supply a 
standard layout of the regcache space, and then have the target vector 
code notify the regcache layer which of those registers it is able to 
supply (or unable to supply if that is more appropriate).

> 	- differing register virtual and raw sizes

That one doesn't worry me any more :-)

R.