This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop mode spec
Nick Roberts wrote:
> > (*) 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.
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? 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.
> > 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.
> Why are there no
> equivalent =thread-exited notifications?
Because it's not implemented. 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).
> >...
> > 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.
> > 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.
Ok. I have not fundamental objections to add CLI commands, however each
CLI command added must be individually examined and its behaviour in non-stop/async
case should be clarified -- which is what I'm trying to do for MI.
> >...
> > - 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)
It's everywhere. The problem is that current GDB does not agree with
the obvious fact that a single-threaded program has a single thread.
Instead, it believes such a program has zero threads. Above is just
one example of the inconsistency. Dan has just posted an in-progress
patch that causes ptid not to change (gaining non-zero tid member)
when program goes from ST to MT, and I have a patch to early add ptid
of the main thread to the thread table, so hopefully we'll have
this sorted.
- Volodya