This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] MI notification on register changes
On Tue, Nov 06, 2012 at 02:04:59PM +0800, Yao Qi wrote:
> 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.
Why?
As soon as a single bit changes somewhere, the only formally correct
response from a frontend is to re-fetch everything.
One can collect several such notification before triggering a full
refetch (no user will insist on updates everyt 50ms, and gdb won't
deliver that anyway), or one can take some risk and not refetch
everything, which in most cases would even be "good enough", but
in general a refetch is needed.
[...]
> 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.
I wouldn't call "false external positives" noisy, unless they generate
so much traffic that there is a performance bottleneck. A frontend
can consciously decide to ignore them.
Andre'