Re: MI non-stop interface details

[Vladimir Prus <vladimir@codesourcery.com>]

On Wednesday 30 April 2008 18:34:48 Pedro Alves wrote:
> 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 think it's the other way around -- add your "resume this thread" button,
and you get your custom behaviour :-)

> > > (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 :-)

Why a frontend would not use --thread for this specific command?

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

I don't believe making -exec-step step just current thread will be perceived
by users as a behaviour change. I bet most users don't know, and don't expect,
the -exec-step command to run random other threads, hit breakpoints in those
threads, etc.

> (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 and I discussed this a bit on IRC, and...]

On IRC, you said:

   [20:40] <pedro> in CLI it's lame to have to know the thread id, and to have to pass it to "continue".
   [20:43] <pedro> break 20; <hit breakpoint>; next; next; <hits other bkreapoint in another thread>; 
   another next; one step; continue; uuups, other thread resumed too...

I think this is valid point -- if user, in CLI, enables non-stop, then having "continue" just work,
resuming one thread, seems right. Are you going to add "--all" to "continue"? Going back to
-exec-continue, it's probably best to make it behave the same way as "continue", in non-stop mode.
This means that a frontend will have to conditionally pass "--all" to -exec-continue, but in
any way, if a frontend enables non-stop mode, is surely has to adjust some of the logic, and changing
-exec-continue logic does not seem too hard.

Thanks,
Volodya