This is the mail archive of the
mailing list for the GDB project.
RE: MI non-stop interface details
- From: "Marc Khouzam" <marc dot khouzam at ericsson dot com>
- To: "Pedro Alves" <pedro at codesourcery dot com>, "Vladimir Prus" <vladimir at codesourcery dot com>
- Cc: <gdb at sourceware dot org>, "Pawel Piech" <pawel dot piech at windriver dot com>
- Date: Tue, 29 Apr 2008 14:56:15 -0400
- Subject: RE: MI non-stop interface details
> > > Can we make -exec-continue/-exec-step/-exec-next consistent, by
> > > making the case of not passing a --thread parameter semantics
> > > match? Given the same arguments, if one resumes just one thread,
> > > the others should too, IMHO.
> > Too late. -exec-continue resumes everything. -exec-step, from user
> > standpoint, resumes one -- most users don't even know that step
> > can resume all threads.
> Oh, I'm talking non-stop mode. It's not too late for that.
> I played a bit with eclipse/java debugging (which implements non-stop),
> and noticed it only resumes one thread when one clicks the
> equivalent of "continue". I have used eclipse/java heavilly in the
> past, and I never found that unintuitive. I remember
> looking for a "continue all" button and not finding one, but normally
> I didn't even thing about it. Resuming one thread was just fine.
> (I keep thinking that in non-stop mode, the exec commands without
> --thread are equivalent to the CLI commands in non-stop mode.
> I keep forgetting to pass --thread to continue& and end up
> resuming more than I wanted.)
I'm also leaning towards this: -exec-continue only continuing
the current thread, a la java.
Although, also having a 'continue all' may prove useful.
For curiosity, what will happen to GDB's 'current thread' if that
thread is continued, i.e., what if we have -exec-continue on a single
thread as suggested above, and we issue two -exec-continue in a row?