read_register_byte can't work with pseudo-reg model

[Richard Earnshaw]

> > I'm guessing. Try:
> >> 
> >> 	if (REGISTER_READ_P ())
> >> 	  {
> >> 	    do something fairly sane;
> >> 	  }
> >> 	else
> >> 	  {
> >> 	    all the legacy cruft including the call to
> >> 	    legacy_read_register_gen() and that test.
> >> 	  }
> >> 
> >> Thing is that there is only one target in the FSF using 
> >> READ_REGISTER_P() so there is this dividing line - something using 
> >> read_register_p() can be given far stronger requirements than for the 
> >> older code.
> > 
> > 
> > Which target is that, and where is READ_REGISTER_P ?  I can't find 
> > anything in the either the source or the mailing lists.  Mind you, the 
> > web-based mailing list search even fails to find your message when I 
> > search for READ_REGISTER_P.

Ok, the following solves my problem; it also makes saving/restoring the 
regcache far more efficient on machines that have that have 
READ_REGISTER_P.

The only assumption is that if this is defined, then pseudos do not need 
unique entries in the regcache (ie they always map onto physical 
registers), so we can copy the regcache simply by iterating over 
0..NUM_REGS.

I need to re-baseline my testsuite runs, but the results look pretty 
encouraging compared to previous runs.

Elena, would this be compatible with the SH model?

R.

	* regcache.c (read_register_bytes): If read_register_p is defined
	and we are saving the entire register set, then short-cut the
	save operation.
	(write_register_bytes): Similarly for write_register_p and restoring
	the register set.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-regbytes.patch
Type: text/x-patch
Size: 1971 bytes
Desc: gdb-regbytes.patch
URL: <http://sourceware.org/pipermail/gdb/attachments/20020516/40a33b65/attachment.bin>