Re: MI non-stop mode spec

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

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

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

 >  > >  >...
 > > 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.
Apple have created an MI command called -break-commands which gets round
this problem for "commands".

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

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