This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
MI: "^running" issues
- From: Vladimir Prus <ghost at cs dot msu dot su>
- To: gdb at sources dot redhat dot com
- Date: Tue, 4 Sep 2007 16:53:21 +0400
- Subject: MI: "^running" issues
I've just run into a somewhat nasty behaviour of gdb.
Suppose if you've set 5 hardware watchpoints (on x86)
and to -exec-step. The output from gdb will be:
(gdb) -exec-next
^running
(gdb)
34^error,msg="...."
The target is not really running at this point, but not that there's no *stopped
message. This is because the "^running" is in error -- it's actually output
when we only start processing -exec-next.
I also recall the long-standing bug that "^running" is not output for CLI
commands.
I really wonder if this is hard to fix? Can we just move the printing of "^running" to
target_resume, to catch all cases? Alternatively, we can notice that "^running" has
double duty if identifying that:
- async operation has started
- target has started
We can make "^running" more focuses by either:
- Introducing "*running" notification, that means the target is running.
- Making "^running" mean that the target has started. As for async/sync
commands, gdb prompt will indicate new command will be accepted.
- Killing the idea of async commands. It does not seem to be very useful
at this point, so we might be better off ripping it and implementing afresh
later, when it's understood what they should be.
Thoughts?
- Volodya