Re: MI non-stop interface details

["Doug Evans" <dje at google dot com>]

On Sat, Apr 26, 2008 at 8:39 AM, Vladimir Prus
<vladimir@codesourcery.com> 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]

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