Re: [RFC] MI notification on register changes

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:

Yao> I also see lval_memory on x86-64, and I am a little surprised that you
Yao> see lval_register.
[...]
Yao> and I think it is reasonable to see 'lval_memory' instead of
Yao> lval_register' here.  When executing this 'set' command, the callchain
Yao> looks like,

Thanks for walking me through it.
I agree this is the intended design.

>> Second, Pedro pointed out this PR:
>> http://sourceware.org/bugzilla/show_bug.cgi?id=7574
>> ... which seems apropos.  It seems that the best thing is a generic
>> "target changed" notification for the reasons mentioned there.

Yao> 'target changed' observer and 'register changed' observer serves
Yao> differently.  'target changed' observer is mostly for keeping gdb
Yao> internal states, such as regcache and frames, consistent, however,
Yao> register changed' observer is for external notifications.

Yao> AFAICS, the reason 'target changed' observer is not replaced by
Yao> memory changed' observer and 'register change' observer is that GDB
Yao> doesn't know the side effect of setting a register or a piece of
Yao> memory, so GDB conservatively uses 'target changed' observer.

I think the implication is that nearly any change can require the front
end to need to reset everything and so trying to make gdb differentiate
between the various events will never work out.  So, gdb might as well
emit something very generic rather than =register-changed.

For example, a register change can affect the variable view, the memory
view (if the register is from some more-outer frame and the user is
viewing the stack), the backtrace view, etc.

Or, a memory change can also affect any of these, including the register
view if the changed memory happens to be where a register is stored.

So, in general, it seems the only safe thing for a front end is to just
refresh everything on any change.

What do you think?

Tom