Re: [RFC] MI notification on register changes

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:

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

In some cases, like breakpoints, gdb has perfect information.
In these situations, sending small changes is easy and efficient.

For memory or registers, I think the PR established pretty clearly that
gdb doesn't have perfect information, or at the very least, that trying
to compute it perfectly would be a lot of work, and so it is preferable
to avoid doing so if possible.

For varobjs, gdb caches the previously sent data so that it can send
deltas.  I think this could be done with other the entities in question
-- registers, memory, stack frames -- if the communications overhead of
a full update is the rate-limiting step.  On the other hand, if the
computation in gdb (including communication with the inferior) is
rate-limiting, then this won't help at all.

Threads are a kind of funny case, see the "finding new threads in the
inferior" item here: http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity

Tom