This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: register != memory
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: "John S. Yates, Jr." <jyates at netezza dot com>
- Cc: gdb <gdb at sources dot redhat dot com>
- Date: Mon, 9 Jun 2003 12:04:37 -0400
- Subject: Re: register != memory
- References: <014401c32ea0$18f21830$1400a8c0@astral>
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