Re: [RFC] MI notification on register changes

[Yao Qi <yao@codesourcery.com>]

On 11/06/2012 04:10 AM, Tom Tromey wrote:
> 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.
>

If GDB emits a very generic notification (for register change, memory 
change, etc), I am not sure how useful it is.  It would be noisy to 
frondend, IMO.
Do we have to emit this notification if the frontend requests to modify 
data in memory? because memory change may affect some register.

> 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.
>

I agree with your points.

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

Not really.  That is true to GDB internal states update, because GDB is 
not clear what is the effect of a register change or memory change.  It 
is safe to reset everything, as you said.  However, for notifications to 
external clients, such as MI front-end, I am not sure it is a good idea 
to emit such notification to MI front-end "everything will be changed" 
just because GDB doesn't exactly know what will happen to the inferior.

My rationale here is like this: for the gdb internal state update, false 
positive (notify observers, but nothing is changed in fact) is fine and 
false negative (something is changed but observers are not notified) is 
not allowed.  For the external notification to clients, false negative 
is fine (it is a limitation of gdb, and will only happen in some corner 
cases), but false positive is noisy.

-- 
Yao