This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop mode spec
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Vladimir Prus <vladimir at codesourcery dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 19 Mar 2008 14:49:17 +1200
- Subject: Re: MI non-stop mode spec
- References: <200803190016.02072.vladimir@codesourcery.com>
> (*) Current MI syntax says that any result record must be followed by a
> prompt. For sync targets, this is wrong -- when gdb prints ^running
> and resumes the target, it does not check for input, so (gdb) is misleading.
> When the target stops, the *stopped message, followed by the prompt is
> printed -- and it's at this point that gdb starts to accept the input
> again. So, I propose to remove the prompt right after ^running for the
> sync targets.
It's not a prompt, just a delimiter. For a start it has a newline after it.
Furthermore if you change the prompt with "set prompt", it doesn't change.
> Each MI command results in either ^done, ^error, ^connected or ^running
> response. The ^connected response is basically identical to ^done,
> and the naming is different for historic reasons. All of those
> except for ^running are immediately followed by prompt. The ^running
> response means that the target has started running. Further events
> from the target will be reported using async notifications.
>
> The async notifications are for various interesting events that cannot
> generally be reported as result of a command. For example,
>
> =thread-created
This notification doesn't appear to be in the manual. Why are there no
equivalent =thread-exited notifications?
>...
> Presently, MI spec says a command can output ^running just once.
> However, it the presense of breakpoint commands, it's quite possible
> that we resume one thread, hit a breakpoint, and breakpoint commands
> resume all threads, or some other thread.
>
> To handle this case we need a new async output for this case:
>
> *running,thread-id="xxx"
^running,thread-id="xxx" ? ("running" isn't an out-of-bound record)
> which is emitted whenever a previously stopped thread is resumed.
> In case all threads are resumed, "xxx" will be "all".
> To simplify things, if GDB is started in MI mode, no CLI command is allowed
> while the target is running, and -interpreter-exec is not allowed either.
If you can make this work with MI commands, it should be easy to add CLI
commands to do the same thing. I will do this.
>...
> - Thread commands. The -thread-info command should be implemented (a
> patch is already posted).
Notice that there is currently an inconsistency here:
-exec-run
^running
(gdb)
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",...
^^^^^^^^^^^^
while
(gdb)
-thread-info
^done,threads=[]
(gdb)
-thread-info 0
^done,threads=[]
(gdb)
b main thread 0
&"b main thread 0\n"
&"Unknown thread 0.\n"
^error,msg="Unknown thread 0."
(gdb)
--
Nick http://www.inet.net.nz/~nickrob