Re: [MI] enabling non-stop mode

[Pedro Alves <pedro@codesourcery.com>]

[ Just a thought dump ]

A Sunday 27 April 2008 08:50:57, Nick Roberts wrote:
>  > >  > Probably, we can extend this to enable feature that are not MI
>  > >  > proper, say:
>  > >  >
>  > >  > (gdb) -list-features
>  > >  >         ^done,features=[....,"non-stop",....]
>  > >  > (gdb) -enable-feature non-stop
>  > >  > ^done
>  > >  >
>  > >  > The only issue here is that non-stop mode availability in general
>  > >  > depends on the target, so maybe we should have a separate commands
>  > >  > to list "target" feature and then enable target features?
>  > >
>  > > Why not just use -gdb-set?
>  > >
>  > > maint set linux-async   -->  set linux-async  -->  -gdb-set
>  > > linux-async maint set non-stop      -->  set  non-stop    --> 
>  > > -gdb-set non-stop
>  >
>  > This will now allow the frontend to check if non-stop mode is supported
>  > at all.
>
> I mean list "non-stop" as a feature, which AFAICS just outputting a string
> field, _and_ do:
>
>     add_setshow_boolean_cmd ("non-stop",...
>
> I don't see the benefit of another MI command like -enable-feature and
> that way non-stop mode can be more easily made available to CLI.

That is how we have it implemented currently, although as
a user command, not a maintenance command, since this is a setting
the user will want to toggle, not just maintainers.  Our current
implementation has:

 (gdb) help show non-stop
 Show whether gdb controls the inferior in non-stop mode.
 Tells gdb whether to control the inferior in non-stop mode.

Which does allow for some for of quering GDB support (not target
support) of non-stop by parsing:

Current GDB:
 (gdb) show non-stop
 Undefined show command: "non-stop".  Try "help show".

GDB with non-stop support:
 (gdb) show non-stop
 Controlling the inferior in non-stop mode is off.

(yes -- non-ideal, and ignores i18n issues)

We can't always know if the target supports non-stop before
the target is active -- think remote.c, where the stub will
have to report if non-stop is supported -- we can't know
if the stub supports non-stop before connecting to it.

We'll want to be able to attach to a live system without
stopping any particular thread, if the target supports that.

Assuming the target supports it, the user will want to set
non-stop mode before attaching to a running target, not
after -- otherwise it may be too late, and some breakpoint may
cause all threads to stop, before the user has a chance
to set non-stop mode.

We currently assume that changing all-stop<->non-stop modes
can only be done while !target_has_execution.

We could have just the global setting, and warn/error as soon
as we detect the target doesn't support it.

-- 
Pedro Alves