This is the mail archive of the
mailing list for the GDB project.
Re: MI non-stop interface details
On Saturday 26 April 2008 20:21:38 Doug Evans wrote:
> On Sat, Apr 26, 2008 at 8:39 AM, Vladimir Prus
> <firstname.lastname@example.org> wrote:
> > At the same time, a suggestion was made to stop GDB to switch the (user-visible)
> > current thread. This will have two advantages:
> > - CLI users won't see the thread switches
> IOW GDB won't switch the current thread on the user, right? [just
> want to understand what you're saying, not to suggest a preference,
> per se]
Yes. GDB will switch its internal "current thread" when processing event,
but it will switch it back to whatever user has last set before processing
next user command.
> > 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.
> Scheduler-locking has two modes, "on" and "step". In case 1 above,
> resuming just a single thread should already work if scheduler-locking
> == "on" (IIUC).
Yes. The question is -- does scheduler locking "off" make any kind of
sense in non-stop mode. If not, we should not support it.
> Having said that, specifying the request in a
> parameter to -exec-* is probably a better way to go.
> IWBN if there was a way to have selective control of which threads run
> (e.g. threads 3,5,7 stay stopped when execution resumes).
> [controlling this in a parameter to -exec-*, as opposed to global
> state, won't necessarily scale though]
There is none, at the moment. I believe Nick has proposed some ways how
this can be done, but there was not a demand for that yet. Maybe they will,
when folks start using non-stop mode.
> > Inferior function calls
> > -----------------------
> > We already have the *stopped async event, and I have a patch to introduce the
> > *running async event. Those are not emitted when doing inferiour function calls,
> > since doing so may cause a frontend to infinitely refresh its state. I propose
> > the following mechanism to enable those notifications for frontends that
> > are sufficiently robust:
> > 1. Declare that MI might have some features that are not enabled by default.
> > 2. Introduce new command -enable-feature, which takes a name of feature and enables
> > it.
> > 3. Make up a name of a feature, say inferior_call_notifications, and add that
> > feature to the output of -list-features.
> > 4. Make '-enable-feature inferior_call_notification' enable *running and *stopped
> > for inferiour function calls.
> 5. Introduce new command -query-feature (?) [assuming it's not there
> already, I don't know]
That will report if a feature is enabled or not? We don't have it (just like we don't have
-enable-feature yet). I'm thinking, though, that for all features we'd document if it's
enabled by default, or not, so this command might not be a big use.