pseudo registers in the regcache

pseudo registers in the regcache

[Richard Earnshaw]

Grepping through the sources for the targets that were using regcache 
entries for pseudos it turns out that in current CVS only two targets are 
using pseudos at all: sh and mc68hc11.


The sh code is known not to put its pseudos in the regcache, which only 
leaves the mc68hc11.

Looking at that code it appears that it uses the pseudos for registers 
that are really part of the memory map, so it seems like we are really 
overloading the "pseudo" name for two different things.

How about renaming the 68k stuff as being MEMORY_REGS and reserving the 
PSEUDO concept for what we really seem to want -- a view of a (or a 
combination of) physical (or memory) register(s)?

That would, I think allow us to say that pseudos are never in the regcache 
and it should simplify many bits of code significantly.

Oh, and I'd make NUM_REGS (the define) be NUM_PHYS_REGS + NUM_MEMORY_REGS 
so that gdb-core sees these as a single resource (ie the separation is 
below gdb-core).

Thoughts?

R.

Re: pseudo registers in the regcache

[Andrew Cagney]

> Grepping through the sources for the targets that were using regcache 
> entries for pseudos it turns out that in current CVS only two targets are 
> using pseudos at all: sh and mc68hc11.
> 
> 
> The sh code is known not to put its pseudos in the regcache, which only 
> leaves the mc68hc11.

Elena?  Is the sh5 clear of all edge conditions?

The mc68hc11 pre-dates register_{read,write}.

> Looking at that code it appears that it uses the pseudos for registers 
> that are really part of the memory map, so it seems like we are really 
> overloading the "pseudo" name for two different things.

The origins of the register_{read,write} stem from a target David Taylor 
encountered that needed to represent memory locations as registers! 
Code that was caching memory values in the register cache had [obvious] 
coherency problems.

> How about renaming the 68k stuff as being MEMORY_REGS and reserving the 
> PSEUDO concept for what we really seem to want -- a view of a (or a 
> combination of) physical (or memory) register(s)?

Or update mc68hc11 :-)

> That would, I think allow us to say that pseudos are never in the regcache 
> and it should simplify many bits of code significantly.

> Oh, and I'd make NUM_REGS (the define) be NUM_PHYS_REGS + NUM_MEMORY_REGS 
> so that gdb-core sees these as a single resource (ie the separation is 
> below gdb-core).

No need.

Andrew

PS:  Or NUM_COOKED_REGS being NUM_RAW_REGS + NUM_PSEUDO_REGS?  Something 
like that is on a few hit lists.  I've been resisting the temptation to 
do this since it was noise compared to eliminating registers[].

Re: pseudo registers in the regcache

[Richard Earnshaw]

> > How about renaming the 68k stuff as being MEMORY_REGS and reserving the 
> > PSEUDO concept for what we really seem to want -- a view of a (or a 
> > combination of) physical (or memory) register(s)?
> 
> Or update mc68hc11 :-)

Well, I was hoping to avoid something that would be regarded as a majorly 
invasive change (and which I've no chance of testing).  Reclassifying the 
mc68hc11 pseudos as memory registers would avoid that (basically it would 
be a search and replace type operation ;-).

R

Re: pseudo registers in the regcache

[Andrew Cagney]

> How about renaming the 68k stuff as being MEMORY_REGS and reserving the 
>> > PSEUDO concept for what we really seem to want -- a view of a (or a 
>> > combination of) physical (or memory) register(s)?
> 
>> 
>> Or update mc68hc11 :-)
> 
> 
> Well, I was hoping to avoid something that would be regarded as a majorly 
> invasive change (and which I've no chance of testing).  Reclassifying the 
> mc68hc11 pseudos as memory registers would avoid that (basically it would 
> be a search and replace type operation ;-).

I'd rather not see GDB do anything to legitimatize a now redundant 
mechanism.

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

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
	- differing register virtual and raw sizes
	- ...
(but worry about that later :-)

enjoy,
Andrew

Re: pseudo registers in the regcache

[Richard Earnshaw]

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

Re: pseudo registers in the regcache

[Andrew Cagney]

> 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