This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI non-stop interface details


A Tuesday 29 April 2008 18:04:57, Vladimir Prus wrote:

> > If we get rid of the auto thread switching, then GDB's current thread
> > will always be the thread the frontend considers current too, because
> > it was the frontend that made it the current thread.  What is this
> > "keeping track" you mention that would be needed for frontends
> > not using --thread?
>
> Suppose that for whatever reason, frontend would like to do anything
> in a thread that is not explicitly selected by a user. Then, frontend gets
> to switch to that thread, do something, and switch back, and should take
> care that no other operation is done while we've temporary switched
> threads.
>

I can't see how is it different -- in the frontend's perspective --
of keeping track of what to pass to --thread= *provided GDB doesn't switch 
threads automatically*.  But then again, I'm no frontend writer.

> > Also, does --thread switch the current thread permanently as if
> > -thread-select was used, or does it only change it for the
> > processing of the command?  That is, should GDB revert to the selected
> > thread after processing an -exec-* --thread command?
>
> Right now, --thread switches the thread permanently. Which is quite fine
> if frontend always adds --thread.
>

I'd have thought it made more sense not to, as that would enable
introducing gradually "--threads" commands in the frontend without
worrying about reverting to the previous thread, but OTOH,
it reduces the amount of switching on the GDB side, and limits the
number of reads from the inferior (read stop pc, for instance)
with the current code base.

> > Not immediatelly.  The *stopped notification will once per thread that
> > reports a stop.  The frontend would use it to update its internal state
> > representing the thread (change the thread icon to a "-like paused icon
> > for instance).  The frontend would send -thread-select when the user
> > activelly clicks on another thread icon (or equivalent action).
>
> Of course, a frontend that, in response to *stopped, will do nothing but
> marking a thread as stopped, will be fairly unpopular :-) Usually, you
> want to show the variables at the stop point, so you'd switch to the stop
> thread.
>

Fair enough. :-)  I realized that after posting.

> > It doesn't seem much different from switching the
> > internal-to-the-frontend notion of current thread, from which the
> > --thread=$id parameter is built.
> >
> > > There are a couple of open questions.
> > >
> > > 1. Presently, -exec-continue resumes all threads, and the current
> > > thread has no effect. I think it's desirable to be able to resume a
> > > single thread, and for that, we actually need the --thread option for
> > > -exec-continue, to mean that a single thread must be resumed.
> > > 2. Presently, -exec-step also resumes all threads. There's an option,
> > > "scheduler-locking" that can be used for cause -exec-step to resume
> > > only the current thread. It seems to be, that for non-stop mode,
> > > resuming all threads is a wrong thing to do, therefore -exec-step, when
> > > in non-stop mode, will resume only the thread been stepped. This will
> > > be the same no matter if the thread is specified implicitly or
> > > explicitly.
> >
> > 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.)

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

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]