Re: [MI non-stop 06/11, RFA/RFC] Report non-stop availability, and allow to enable everything with one command.

[Vladimir Prus <vladimir at codesourcery dot com>]

On Friday 11 July 2008 17:34:17 you wrote:
> A Saturday 28 June 2008 17:54:03, Vladimir Prus wrote:
> > This patch allows MI frontend to query for non-stop support, like this:
> 
> > Another issue is direct poking at linux async support. I do think that
> > we need global 'async' variable to implement this cleanly.
> 
> Yeah, I think so too.  Shouldn't be hard to do.
> 
> > Comments?
> >
> 
> Since you're adding a target method, let's think a bit about this
> issue:
> 
> What happens in these cases:
> 
>  GDB build as native linux debugger, we don't support non-stop in remote yet:
> 
>  (gdb) set non-stop 1
>                          OK, the default run target supports non-stop.
> 
>  (gdb) tar rem foo:9999
>                          OK, connected
> 
> Is the non_stop global on now?  The debug session will be badly broken if
> so.
> 
> ----
> 
> Fast forward a couple of weeks, when non-stop in the remote target
> is committed,
> 
> GDB built as mingw32 native debugger, 
> 
>  (gdb) set non-stop 1
>                          failure, the default run target doesn't support
>                          non-stop.
> 
>  (gdb) tar rem foo:9999
>                          OK, connected in all-stop.
> 
>  (gdb) set non-stop 1
>                          Error, target has execution.
> 
> Basically, no way to enable non-stop in this case.  :-(

Gah; I've forgotten that presently, you cannot change to non-stop when
target has execution. I assumed the frontend would first select a target
(or implicitly select the default one), then set non-stop, and never
touch the target again.

I think we have two possible approaches now:

1. Make 'non-stop' variable mean 'I want non-stop, from all targets that
support it'. Then, the internal 'non_stop' variable will be true when the
current target does support non-stop, and the user-level non-stop variable will
correspond to some non_stop_request variable, which will be consulted each time
we change targets. There should be a way to query if the target really supports
non-stop.

2. Make 'set non-stop 1' work even if the target has execution. I actually not
sure why the error is emitted currently. If the target is fully stopped when
we do "target remote foo:9999", then changing non-stop setting should not have
any bad effect. We'd have to reset non-stop back to 0 when pushing targets --
either unconditionally, or when the new target is not non-stop capable.

What do you think? (2) seems more clear to me.

- Volodya