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