Re: MI non-stop mode spec

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

 > > 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.
 > 
 > Let's call (gdb) a "MI prompt", then. Given that each MI output is already
 > terminated with a newline, (gdb) is not necessary to property parse MI
 > output. Then, the question is that does (gdb) mean?

Well I've not tried to parse the MI output on it's own, in earnest, yet but if
it's a delimiter then means that the parser can find the end of the output
record.

 >                                                     If it does not mean 
 > anything, it should be, ideally, just removed. And if it means anything,
 > then what? Current behaviour is not consistent, but the code suggests
 > that it's meant to indicate when GDB is ready for a new command. I think
 > such a behaviour will be useful for a frontend.

If it stays, the frontend can just use the rule that GDB is ready for a new
command after "(gdb)\n" unless it's preceded by ^running.

 > >  > 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.  
 > 
 > Because I'm still working for a doc patch for same.

According to the syntax, as above, this should be:

     =thread-created,id="3"
     (gdb)

 > > Why are there no 
 > > equivalent =thread-exited notifications?
 > 
 > Because it's not implemented. 

Does that mean that you think that =thread-created is more useful?

 > Note that current thread.c implementation will only declare a thread as done
 > when we do -thread-info (or anything else that calls prune_threads, so the
 > value of =thread-exited will be limited, without some associated work on
 > threads layer).

I'm not sure what you mean.  If I run Gdb normally with a multi-threaded
application, I get:

[New Thread -1210639472 (LWP 7235)]

when a thread is created and:

[Thread -1210639472 (LWP 7235) exited]

when it is terminated.


 > >  > 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)
 > 
 > "*running" is the new async output proposed by this spec (and async-output
 > is a kind of out-of-bound record). We cannot use ^running, because ^running
 > is emitted once for each command, and each command can resume the target
 > several times, and possibly - different threads.

Breakpoint command lists don't currently work in MI, so your scenario is a bit
hypothetical, but if they did then it's quite possible that we hit a breakpoint
on one thread and breakpoint commands resume all threads without async mode.

It probably doesn't matter that much if you use "*running" or "^running" and
you can probably define asynchronous in different ways but I think starting
execution and detecting stopped execution different in this respect.

-- 
Nick                                           http://www.inet.net.nz/~nickrob