This is the mail archive of the
mailing list for the GDB project.
Re: MI non-stop interface details
- From: "Doug Evans" <dje at google dot com>
- To: "Vladimir Prus" <vladimir at codesourcery dot com>
- Cc: gdb at sourceware dot org, "Pawel Piech" <pawel dot piech at windriver dot com>, "Marc Khouzam" <marc dot khouzam at ericsson dot com>
- Date: Sat, 26 Apr 2008 09:21:38 -0700
- Subject: Re: MI non-stop interface details
- References: <firstname.lastname@example.org>
On Sat, Apr 26, 2008 at 8:39 AM, Vladimir Prus
> 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,
> 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). 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]
> 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
> 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]