Re: register != memory

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Jun 09, 2003 at 11:59:24AM -0400, John S. Yates, Jr. wrote:
> Being well into implementation of a remote stub
> for an embedded environment I have a few thoughts
> to share.
> 
> Foremost among these is gdb's modeling of target
> registers.  The model seems to presume vanilla
> registers (e.g. gprs, fprs, pc, etc).
> 
> To provide the low level access needed by many
> of our developers I have exposed many kernel-only
> registers via g, G, and P.  Sadly the results
> leave something to be desired because gdb seems
> to believe that it can employ a memory-like model
> for caching registers.
> 
> This breaks down when the user sets one of these
> kernel-only registers.  I have numerous examples
> where this results in a corrupted register cache:
>   - readonly registers
>   - bits that always read as zero or one
>   - write-one to clear bits
> 
> Since the G message seems to be associated with
> establishing thread state I simply ignore values
> for any register that is not multiplexed by the
> thread scheduler.  
> 
> The P message is more of a problem.  Even when
> returned an error (e.g. an attempt to modify a
> readonly register) gdb reports the error to the
> user but still updates its register cache.
> 
> A clean solution might be to allow an alternate
> reply to a P message: Rval supplying the value
> to be encached.

I think we need this in general for G also... I have a wishlist bug
report asking for one of the PPC system registers to be updated
correctly after setting it, since the kernel filters legally changeable
bits.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer