Re: [RFA] regcache.c (register_fetched) + related changes

[Andrew Cagney <ac131313@cygnus.com>]

> Example, for this processor, the frame pointer is a pseudo register.
> The frame pointer is two random 8 bit registers -- 16 bits.  The
> hardware does *NOT* have the ability to operate on those registers as
> a pair.  It cannot load the frame pointer, it cannot store the frame
> pointer, it can only load or store one of the 8 bit registers at a
> time.
> 
> Since the compiler writer simply chose two adjacent 8 bit registers,
> in the right order, there is no need, in REGISTER_BYTES to have a
> special place for the fp and then copy things back and forth --
> instead the value goes directly into the two underlying real
> registers.
> 
> So, when the fp is fetched, there is a need to mark the underlying
> real registers (i.e., registers in the range [0,NUM_REGS) as fetched.

Yes.

That is a design flaw in the way GDB currently handles FP and other
pseudo registers.  At first sight you think that something like
write_pseudo() can be implemented as just:

	read_register_gen(..., first half);
	read_register_gen(..., second half);

Unfortunatly, because of some broken code in the core of gdb still also
need to allocate space in the regcache and pull all sorts of nasty
hacks.

The idea of separating a core-gdb register write from the raw register
cache (so that write_pseudo() can do a scatter.  Should fix that.  I was
planning on such a change as part of binding everything to a frame,
however, that could be separated out.

	Andrew