register != memory

[Andrew Cagney]

> Foremost among these is gdb's modeling of target
> registers.  The model seems to presume vanilla
> registers (e.g. gprs, fprs, pc, etc).

After writing to a register, everything is invalidated.  Is this not 
happening?

Andrew


> 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.
> 
> /john
> 
>