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

Vladimir Prus
2008-07-23T07:48:57Z

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