enabling non-stop mode

Hello,

I'm thinking about the best interface to query for, and
enable non-stop
mode when using MI.

We presently have the -list-features command that list
various things GDB
supports.

I've already proposed to add -enable-feature command to
enable things
that are off by default.

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?

Thoughts?

- Volodya

 > 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

I thought the idea of -list-features was to give the
frontend a simple means of
finding out which MI commands a version of Gdb will accept. 
Why would a
frontend want to do "-disable-feature
frozen-varobjs"?

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

 > 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

I thought the idea of -list-features was to give the
frontend a simple means of
finding out which MI commands a version of Gdb will accept. 
Why would a
frontend want to do "-disable-feature
frozen-varobjs"?

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

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

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

[ 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

On Sat, Apr 26, 2008 at 10:16:16PM +0400, Vladimir Prus
wrote:
> I've already proposed to add -enable-feature command to
enable things
> that are off by default.

I agree with Nick; this sounds like -gdb-set.  If you need
to give the
front end information about whether something is supported
(by this
GDB or by this target), why not use -gdb-show for that?

Then -gdb-show could report "off (not supported by this
target)" in
whatever format was convenient.

-- 
Daniel Jacobowitz
CodeSourcery