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


On Tuesday 29 April 2008 21:48:51 Pedro Alves wrote:
> 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.

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.

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

- VOlodya


 



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