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