RE: [RFC] h8300 "info registers" fix

["Yoshinori Sato" <ysato at users dot sourceforge dot jp>]

>
>> 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 size is converted by the access of a pseudo 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).

Because legacy_register_sim_regno was not able to judge the register
number correctly, it corrected it.
However, it is necessary to evade this problem with register_sim_regno.
It corrects it like that.

> 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
>

Thank you for the advice that becomes reference very much.

-- 
Yoshinori Sato
<ysato@users.sourceforge.jp>