[MI] enabling non-stop mode

[MI] enabling non-stop mode

[Vladimir Prus]

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

Re: [MI] enabling non-stop mode

[Nick Roberts]

 > 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.nz/~nickrob

Re: [MI] enabling non-stop mode

[Nick Roberts]

 > 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.nz/~nickrob

Re: [MI] enabling non-stop mode

[Vladimir Prus]

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

Right; not all versions of GDB, and not with all targets, will support non-stop
mode.

> Why would a 
> frontend want to do "-disable-feature frozen-varobjs"?

It should not do that, that's why only some of the features will be documented
as user-togglable.

- Volodya

Re: [MI] enabling non-stop mode

[Nick Roberts]

 > >  > 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.nz/~nickrob

Re: [MI] enabling non-stop mode

[Pedro Alves]

[ 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

Re: [MI] enabling non-stop mode

[Daniel Jacobowitz]

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