This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] MI notification on register changes

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]