register != memory

register != memory

[John S. Yates, Jr.]

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.

/john

Re: register != memory

[Daniel Jacobowitz]

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

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