RE: [RFC] MI notification on register changes

[Marc Khouzam <marc.khouzam@ericsson.com>]

> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com] 
> Sent: Wednesday, November 07, 2012 12:01 PM
> To: Marc Khouzam
> Cc: 'André Pönitz'; 'Yao Qi'; 'Tom Tromey'; 
> 'gdb-patches@sourceware.org'
> Subject: Re: [RFC] MI notification on register changes
> 
> Marc Khouzam wrote:
> 
> >> André Pönitz wrote:
> >> On Tue, Nov 06, 2012 at 02:04:59PM +0800, Yao Qi wrote:
> >>> 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.
> 
> The issue is in the "contain the changed info" part.  In 
> general, we don't have such
> info available.  So there are cases where trusting such fine-grained
> notifications will get you stale views.  For example, in the 
> general case, if the
> user changes registers/memory, we can't assume that 
> memory/registers didn't change.
> Some targets even have memory-mapped registers.  If GDB core 
> shouldn't assume such
> things, then "registers changed" or "memory changed" 
> notifications are in general
> misleading.  We'd have to add notes like "note that even 
> though we're saying only
> a register changed, everything else (memory, stack frame, 
> whole stack, etc.)
> might have changed too, so you're better off refreshing all 
> your views." which may
> be a bit silly.  We may be better off not giving ourselves 
> and the frontends rope to hang ourselves with.

Ok, I understand the problem now.
It should probably up to GDB to determine, if possible,
the safe cases which can specify the "changed info" and 
the unsafe cases which should not, therefore telling the 
frontend to do a full refresh.  Which brings your next
question:

> The related question is then, why is a full refresh an issue, 
> if that is something
> the must already do after every stop, such as e.g., after 
> each "step".  As PR 7574
> hints at, things like "step" are the use cases users will 
> notice and complain
> the most if slow.  It seems like optimizing the frontends 
> with selecting/partial updates
> for some cases still leaves you with needing to optimize the 
> full-refresh case
> anyway for more important cases.

Avoiding a full refresh is probably a result of inertia.
Since GDB allows the frontend to try to avoid a full
refresh by giving extra information in its notifications,
the idea of continuing with that approach seemed the right one.
For instance, GDB could have a single =breakpoints-changed
notif which would trigger a full refresh a breakpoints.
Same for variable objects (see -var-update).  Even
=threads-changed (although this may be a little more
justified if we think about it more deeply).

Fundamentally, erroneous data is the worse case.  So,
having a notification without "changed data" is better 
than an invalid or incomplete "changed data", or no
notification at all :).

So, if there are cases where a full refresh is needed
then I can understand that it may not be worth trying
to provide the "changed data" only once in a while.

Thanks for the explanation.

Marc