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