This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] MI notification on register changes
On 11/03/2012 12:42 AM, Tom Tromey wrote:
First, Yao sees that lval_memory on x86, but I don't see it on x86-64.
I wonder whether it is a bug elsewhere.
I also see lval_memory on x86-64, and I am a little surprised that you
(gdb) b middle
Breakpoint 1 at 0x40056d
Starting program: gdb/testsuite/gdb.base/nodebug
Breakpoint 1, 0x000000000040056d in middle ()
#1 0x000000000040059d in top ()
(gdb) p/x $rbp
$1 = 0x7fffffffe5a0
(gdb) set $rbp=0x7fffffffe5a0
Breakpoint 1, value_assign (toval=0xdaf7a0, fromval=0xe36170) at
1246 switch (VALUE_LVAL (toval))
$1 = lval_memory
and I think it is reasonable to see 'lval_memory' instead of
'lval_register' here. When executing this 'set' command, the callchain
' case OP_REGISTER: value_of_register
frame_register (frame, regnum, &optim, &unavail,
&lval, &addr, &realnum, raw_buffer);
VALUE_LVAL (reg_val) = lval;
The 'lval' can be set to 'lval_register' or 'lval_memory' in
frame_register. So I don't see anything wrong here.
Second, Pedro pointed out this PR:
... which seems apropos. It seems that the best thing is a generic
"target changed" notification for the reasons mentioned there.
'target changed' observer and 'register changed' observer serves
differently. 'target changed' observer is mostly for keeping gdb
internal states, such as regcache and frames, consistent, however,
'register changed' observer is for external notifications.
AFAICS, the reason 'target changed' observer is not replaced by 'memory
changed' observer and 'register change' observer is that GDB doesn't
know the side effect of setting a register or a piece of memory, so GDB
conservatively uses 'target changed' observer.