Re: MI non-stop mode spec

[Nick Roberts <nickrob@snap.net.nz>]

 > (*) 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