Re: [RFC] MI notification on register changes

[Yao Qi <yao@codesourcery.com>]

On 11/08/2012 01:00 AM, Pedro Alves wrote:
> 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

It sounds like a 'memory model' (it is not proper here, but that is the 
term I can think of), a single write to register or memory may cause 
different effects.

If we want to solve this problem in GDB side, we need a precise and 
accurate target description to address them below, don't we?

   1) modify register FOO will update memory area 0xN ~ 0xM, and vice versa,
   2) register BAR is read only, or at least some bits are.
   3) this target doesn't have these special hardware features,

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

Supposing gdb has this precise target description, gdb doesn't have to 
refresh everything else, otherwise gdb has to conservatively update 
everything like what it does nowadays.  Do you agree?

-- 
Yao