RE: [RFC] h8300 "info registers" fix

["Michael Snyder" <Michael dot Snyder at palmsource dot com>]

> A result of ccr and exr mistakes by a "info registers" of h8300 target.
> There was two faults.
> 
> - A name of E_CCR_REGNUM is not defined with h8300_register_name.
>   Accordingly regcache_raw_read of h8300_pseudo_regitser_read fails.
> - Assume size of E_PSEUDO_CCR_REGNUM by 1 byte with h8300_register_type.
>   But assume 4 bytes from a remote target.
>   Accordingly cannot take response of remote side to be really.
> 
> I correct an issue of a thing of the patch box which I attached.
> The issue was corrected, but not know you whether this is good technique.

I'm sorry, but I don't think this is right.  

E_CCR_REGNUM is the physical register which gdb reads from the target.
This is defined to be 4 bytes, even though only 1 byte is significant.
It's just easier to keep most or all of the registers to the same size
within the register message packet.

E_PSEUDO_CCR_REGNUM is a "pseudo-register", which gdb computes internally
(rather than requesting from the target).  It is defined to be 1 byte, and
it is the register that gdb displays to the user.  In this case, the 
computation of the pseudo-register is simply copying the one significant
byte from the physical register.

The fact that E_CCR_REGNUM has no display-name is deliberate.  That
register is never displayed, it is only fetched from the target and
used to obtain the value of E_PSEUDO_CCR_REGNUM (which is displayed).

If you are working on the target side (gdb stub, simulator, or gdbserver), 
you only have to worry about E_CCR_REGNUM, but you need to supply it as
four bytes.  I forget whether the MSB or the LSB is the significant one,
but you should not have too much trouble to figure it out.  The other
bytes can be any value - they'll be ignored.

Michael