RE: MI non-stop interface details

["Marc Khouzam" <marc dot khouzam at ericsson dot com>]

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

Thanks

Marc