Re: MI non-stop mode spec

[Vladimir Prus <vladimir@codesourcery.com>]

On Wednesday 19 March 2008 12:14:19 Nick Roberts wrote:
>  > > 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.

And what's the practical value? Both KDevelop and CDT parse MI output line-by-line,
and it appears to be just enough.

>  >                                                     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.

Which happens to be wrong. In async mode, gdb *may* be ready for a new
command even if ^running is output. And whether it's ready or not, generally
depends on the command

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

And what is the value of (gdb) here?
 
>  > > 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?

It's easy to implement.
 
>  > 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.

At which point, and where in code is that message printed? It is
printed by linux-thread-db.c:detach_thread, so it's not good for
generic code. And generic code will hold on to thread until 
"info thread". It's not very good if you need to issue "info thread"
to get notifications about exited thread.

So, thread.c and its interaction with linux-thread-db.c have to
be fixed.

>  > >  > 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, 

Do you suggest they should never work? They probably don't work because nobody
tried to make them -- we have a call to bpstat_do_actions in 
mi_interpreter_exec_continuation so we try to do them only for CLI commands,
and only in async mode.

> 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.

Yes, and what's wrong about that? We still need to accurately report to
the frontend which threads are running, so that the frontend does not
allow the user to mess with the currently running threads.

> 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.

I have a simple goal -- at any point, the frontend should know exactly:

1. Which threads are there.
2. Which threads are running or not

The second requires that we always report when currently-stopped thread
gets running, and this might require more than one notification. Since ^running
is now specified as emitted once we have the following choices:

1. Say that ^running can be emitted several time. But then, why can't be allow
^done to be emitted many times? And if we do, the point of ^ responses disppear.
2. Say that ^running is bad design to begin with. Replace ^running with *running.
Declare that -exec commands result in ^done.
3. Leave ^running along. Add *running that naturally can be printed several
times.

I personally prefer (2), but it's more drastic change for frontends, so
I've suggested (3) for now.

- Volodya