Re: [RFA] register_modified_event

[Andrew Cagney <ac131313@ges.redhat.com>]

> On Mon, 19 Aug 2002, Andrew Cagney wrote:
> 
> 
>> I don't the register_modified (the changelog called it register_update) 
>> is correct.  Trying to supply a register number, for instance, is just 
>> misleading.
> 
> 
> (ChangeLog is wrong, of course. It should be register_modified, not 
> register_update.) As for supplying register numbers, I think you'd 
> better take another look at MI's command set. Everything (except 
> data-list-register-names) returns register numbers. In fact, there is no 
> way to find out what the numbers mean at all with the current MI command 
> set!

(We're not talking about register numbers vs names.  You can figure out 
a name/number map from the command that returns the register names.  The 
current implementation is broken in that on some targets, it will leave 
gaps.  That can be fixed by either changing the interface or the code :-)

The problem here is that trying to include the ``modified register'' in 
the event is misleading to the point of being dangerous.  The best MI 
can offer the GUI is ``hey, target-changed!''.  Every time the target 
changes, the GUI needs to refresh everything via varobj.

> I presume that you mean this thread:
> 
> http://sources.redhat.com/ml/gdb/2002-03/msg00154.html
> 
> I guess Jim thought there were bigger fish to fry. So if a global
> "target-changed" event is wanted, when is it to be sent?

My understanding of JimI's comments (and I agree) is that nothing 
matters except how long it takes for the GUI to recover from a target 
changed (eg from inferior execution).

Given that single step refresh performance sets an upper bound on on 
memory/register write refresh performance, people will always notice a 
slow single-step long before they notice slow writes.

> When:

These change the target:

> o register changed by user (either via command-line or other UI)
> o memory changed by user (")
> o inferior execution

These do not change the target:

> o user changes threads (thread_command)
> o user changes stack levels (frame_command, up_command, down_command)

See also:
http://sources.redhat.com/gdb/papers/multi-arch/real-multi-arch/index.html#SEC33

enjoy,
Andrew