This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop mode spec
> > 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