Re: MI non-stop mode spec

[Vladimir Prus <vladimir@codesourcery.com>]

On Wednesday 19 March 2008 15:00:29 Nick Roberts wrote:
>  > > 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.
> 
> Maybe you're right but the "(gdb) \n" doesn't seem to cost much.

It make it impossible to know if gdb is ready for input.

>  > >  >                                                     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
> 
> In async mode Gdb is pretty much always ready for a new command isn't it?

Not necessary. For example, presently calling of function in inferior is
not async, and making it async is fairly complex.

>  >  > >  >...
>  > > Breakpoint command lists don't currently work in MI, 
>  > 
>  > Do you suggest they should never work? 
> 
> No, but breaking my sentence here might make it appear that I did.
> 
>  >                                         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.
> 
> CLI commands like "commands" that query the user don't fit well with MI.

Well, I can set breakpoint commands in MI just fine, it's just they
are not run.

> Apple have created an MI command called -break-commands which gets round
> this problem for "commands".

Yes, it's not very hard to grab, in fact.
 
>  > > 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.
> 
> There's nothing "wrong" about that, just that apart from adding the thread id,
> I can't see much difference to the present case.
 
Is it either:
1. You don't believe that a single command can result in more than one resumption,
of different threads?
2. You think it's fine to emit ^running several times?

- Volodya