This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] register_modified_event
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