Re: [RFC] MI notification on register changes

[Pedro Alves <palves at redhat dot com>]

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.

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.

-- 
Pedro Alves