Re: MI non-stop interface details

[Vladimir Prus <vladimir@codesourcery.com>]

On Saturday 26 April 2008 20:21:38 Doug Evans wrote:
> 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]

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.

- Volodya