read_register_bytes() bug; was my Regcache revamp
Andrew Cagney
ac131313@cygnus.com
Sat Aug 18 11:08:00 GMT 2001
To quote my original e-mail:
http://sources.redhat.com/ml/gdb-patches/2001-03/msg00312.htm
> Hello,
>
> This patch may change your life!
>
> Well, yes, ok, I'm probably being a little dramatic! However, it
> certainly does change the way targets implement pseudo/cooked registers.
>
> The attatched patch revamps the regcache interface along the lines
> described in:
Well its taken 5 months but I've finaly found a ``bug'' this change
introduces.
The old read_register_bytes() had the logic (greatly simplified):
o go through all registers
and read each valid (as defined
by REGISTER_NAME()) register
into the cache
o copy out the relevant raw bytes
from the register buffer
the new code combined those two:
o go through all registers
if valid (as defined by REGISTER_NAME())
read the register into the cache
write the register into the buffer
The problem is that the register cache can have ``holes'' in it. An
invalid/ignore/dne REGNUM, as determined from REGISTER_NAME(), can still
occupy space in the register buffer. The old code was blindly copying
the contents of the holes. The new code, skips them, leaving them
undefined - typically picking up garbage from the heap.
This shouldn't hurt since the holes are invalid/ignored/dne/... right?
Nope, a target was getting that ``invalid data'' and then using it - the
corresponding write_register_bytes() doesn't skip invalid/ignore/dne
REGNUMs.
I think the ``real bug'' is that the updated read_register_bytes() can
leave part of the buffer undefined. I'm thinking of either changing
things to:
o initializing the gaps from
the regcache (restoring old
behavour)
o initializing the gaps with
0xdeadbeaf.
I am very tempted to implement the latter but suspect I'll be forced to
implement the former, Sigh!
Andrew
More information about the Gdb-patches
mailing list