read_register_bytes() bug; was my Regcache revamp

[Andrew Cagney <ac131313@cygnus.com>]

To quote my original e-mail:

http://sources.redhat.com/ml/gdb-patches/2001-03/msg00312.htm

 > Hello,
 >
 > This patch may change your life!
 >
 > Well, yes, ok, I'm probably being a little dramatic!  However, it
 > certainly does change the way targets implement pseudo/cooked registers.
 >
 > The attatched patch revamps the regcache interface along the lines
 > described in:


Well its taken 5 months but I've finaly found a ``bug'' this change
introduces.

The old read_register_bytes() had the logic (greatly simplified):

	o	go through all registers
		and read each valid (as defined
		by REGISTER_NAME()) register
		into the cache

	o	copy out the relevant raw bytes
		from the register buffer

the new code combined those two:

	o	go through all registers
		if valid (as defined by REGISTER_NAME())
			read the register into the cache
			write the register into the buffer

The problem is that the register cache can have ``holes'' in it.  An
invalid/ignore/dne REGNUM, as determined from REGISTER_NAME(), can still
occupy space in the register buffer.  The old code was blindly copying
the contents of the holes.  The new code, skips them, leaving them
undefined - typically picking up garbage from the heap.

This shouldn't hurt since the holes are invalid/ignored/dne/... right?
Nope, a target was getting that ``invalid data'' and then using it - the
corresponding write_register_bytes() doesn't skip invalid/ignore/dne
REGNUMs.

I think the ``real bug'' is that the updated read_register_bytes() can
leave part of the buffer undefined.  I'm thinking of either changing
things to:

	o	initializing the gaps from
		the regcache (restoring old
		behavour)

	o	initializing the gaps with
		0xdeadbeaf.

I am very tempted to implement the latter but suspect I'll be forced to
implement the former, Sigh!

	Andrew