RE: [RFC] MI notification on register changes

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of André Pönitz
> Sent: Tuesday, November 06, 2012 3:00 PM
> To: Yao Qi
> Cc: Tom Tromey; gdb-patches@sourceware.org
> Subject: 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.

IIUC, the notifications being proposed will only be triggered if
registers are changed by the user.  This is something that the frontend
needs to be told about because the assumption is that registers/memory
are stable when the program is suspended.  I don't believe a full
refresh is needed if such notifications contain the changed info.

Register changes caused by program execution are not targetted
by this notification, or at least I don't think they should be.

Marc


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