Re: pseudo registers in the regcache

[Andrew Cagney <ac131313@cygnus.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).

Knowing some of the older targets, I don't expect most to be affected at 
all by such a change - they already have a simple 1:1 cache layout and 
only raw registers.  Of the others, the ones that are most affected by 
such a change are also the ones that most desperatly need a cleanup -> MIPS.

Are there too many legacy interfaces?  I just did a:
   $ grep legacy *.h | grep -v -e '^gdbarch' -e '^arch-'
so I think we need more of them :-^ :-^

I believe most of the current legacy code is to prop up non-multi-arch 
architectures and get around limitations in the multi-arch framework. 
As the old targets go and the problems are fixed the number will start 
to go down.

Here, yes, we've got different situtatioin.  Check the thread:
http://sources.redhat.com/ml/gdb/2001-03/msg00124.html
for various opinions on how to approach this.

(Hmm, I've been falling down on the legacy side but I have managed to 
doco the multi-arch process.)

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

Sorry ``hole'' is a loose term.  I'm thinking of the nasty things that 
can be done with register_byte() and register_raw_size().  Regsters of 
size zero, gaps between RawRn and RawRn+1, register_byte(PseudoRn) == 
register_byte (RawRm) + CONST, ....  The MIPS is guilty as charged.

----

Another problem with the way things currently work.  OP_REGISTER is 
implemented as an offset and size into the register cache. 
read_register_bytes is then used to read it.

I should add an interface to regcache to keep that working :-(

Andrew