Re: MI non-stop interface details

[Pedro Alves <pedro at codesourcery dot com>]

A Wednesday 30 April 2008 07:59:43, Vladimir Prus wrote:
> On Tuesday 29 April 2008 21:48:51 Pedro Alves wrote:
> > A Tuesday 29 April 2008 18:04:57, Vladimir Prus wrote:
> > > > Pedro Alves wrote:
> > > > 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.
>
> Opinions differ. I think Eclipse behaviour optimized for non-common
> cases. Maybe this non-stop behaviour is good for that J2EE kind of thing,
> with zillion of threads, but it's not a good default behaviour for
> debugging ordinary applications.
>

Eh, indeed my experience is mostly with debugging live J2EE systems.
It's also a bless to be able to hot-replace code while debugging, but
well, java makes it easier to implement. :-)   I won't claim what
is common or non-common without data.  Clearly, add a "resume all"
button/shorcut and you get your "common" behaviour implemented.

> > (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.)
> >
> > > > If we choose to always ignore the scheduler-locking setting
> > > > in non-stop mode, by making them operate on the current thread
> > > > only, we can still honour '-exec-continue --thread="all"',
> > > > or '-exec-step --all'.  If people find it desirable, we can
> > > > make "scheduler-locking off" with no --thread specified mean resume
> > > > all threads.  That I tend to agree is wrong in non-stop mode.  I'd
> > > > rather have two buttons on the IDE -- "resume" and "resume all",
> > > > (or two keyboard shortcuts, etc.) then to export the sheduler-locking
> > > > modes to the user interface.
> > >
> > > I guess we can redefine the behaviour of -exec-continue in non-stop, or
> > > in MI3, but I worry that two different behaviours will make life too
> > > hard for frontends (and for us)
> >
> > Oh, I was talking non-stop.
>
> I don't think that adding a bunch of "if (non_stop)" is gonna be a good
> solution.

Oh well, on the GDB side, there's no way around it.  Inferior control
in non-stop is different.  In non-stop, we have to resume every
thread individually in common code, and while doing it, we have to
make sure every thread is resumed with its context set.
While in all-stop, there's always only one thread with an event to
attend, and all other threads have been freezed by the debugger.  When
we resume, in all-stop it's the target's responsibility to resume the
frozen threads.
A resume all in non-stop has also to take care of not resuming already
running threads -- more accuratelly it's "resume-all-stopped".  This
worry doesn't exist in all-stop.

Unless you were talking about that check in the frontend side.  Have
no idea what would change, but I'd expect at least a bit of work to
enable non-stop, just not a rewrite.

If we don't make "-exec-continue" resume only the selected thread, then
a frontend not using "--thread" should set "set scheduler-locking on"
to have a way of resuming just one thread, and GDB should
honour scheduler-locking modes in non-stop mode.  This is the part
I want to have settled, as I get to tweak to code :-)

Does this mean "-exec-step" with no "--thread"
and "scheduler-locking off" should step every stopped thread?  I assume
not, it's not intuitive, but it's not really the same as in all-stop,
where we step one thread and resume all others, which is a
behaviour change too.

(Well, we could do non-stop do that too --step current, and
resume others, meaning that non-stop with scheduler-locking off
would be similar to all-stop, *except* we don't stop all threads
when the step finishes...  If we do that in common code, then,
it starts looking like we could turn "non-stop on" always, and
implement all-stop on top of it -- not really sure if that should
be a goal, or is it is possible at all, and I was going to defer
thinking about it until later on, otherwise we'll never get this done.)

-- 
Pedro Alves