register != memory

["John S. Yates, Jr." <jyates at netezza dot com>]

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