This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] MI notification on register changes
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
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.