Re: The REG_NUM and REGISTER_BYTES problem

[Andrew Cagney <ac131313@cygnus.com>]

> Well, how will this affect pseudo registers that we can provide but
> that the remote stub can not?  I'm pretty sure there are some.  Is the
> intent that such registers "should not" be fetched?

Hmm, yes, er, how can I put it?  Pseudo registers are a figment of GDB's 
vivid imagination?  Hmm, perhaphs not.

The theory is that core-GDB delegates _all_ responsibility for the 
resolution of such issues to the target architecture.  Or to put it 
another way, the target architecture is given enough rope to hang its 
self :-)

Yes, there are going to be registers that should not be fetched by 
remote.c from the target.  The trick is that register read/write should 
have already intercepted such register requests and mapped them onto 
real registers. (ok, I've simplified it a little :-)

Think of it as:

	user
	-> register read/write (maps cooked to raw)
	-> regcache read/write
	-> target fetch/store
	-> target.c
	-> map regnum to target regnum

provided register read/write is implemented correctly, the architecure 
is honky dorey.

To give a tangeable example, consider i386's MMX.  These 64 bit pseudo 
registers can be mapped onto 80 real FP registers.  The register 
read/write function map's MMX N register onto FP register M.

enjoy,
Andrew