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

Pedro Alves
2008-07-28T17:58:20Z

On Wednesday 23 July 2008 08:48:26, Vladimir Prus wrote:
> 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.

In most targets that allow selection with "target remote/sim/etc", when
you select them, you also implicitly get execution. E.g.,
"target remote" vs "target extended-remote". Even connecting
with extended-remote can find that the stub was already controling
some inferiors, (due to the "?" packet). We may even have
a stub that only supports non-stop, and doesn't stop the inferior on
connection (say "target remote" into a running OS). The connection setup
phase already needs to know if we're trying to use non-stop or not, so,
chosing non-stop only after target selection will not work out.

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

The thing is that with native targets, we can mostly (*) tell upfront if
they support non-stop, but with remote targets, only after connection can
we tell if the stub supports it (stub will report with qSupported). We
have to assume no support by default.

(*) Not quite true. We can ask the default run target (process_stratum),
but support for non-stop, which requires scheduler-locking and tweaking
with threads, may or may not be supported by the thread_stratum target
that ends up being pushed. There are OSs where there is more than
one possible thread_stratum target (e.g., BSD's and kernel vs user
threads).

> 2. Make 'set non-stop 1' work even if the target has execution. I actually
> not sure why the error is emitted currently.

Because at the current state of inferior control, it is hard to move
between non-stop <-> all-stop when there's already an inferior under
control. That may change, especially after getting rid of context-switching
(Real Soon Now (TM)) but that's how things are 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.

I still can't tell what might be better. E.g., this is how
currently connection with the remote target with non-stop support looks
like:

remote.c:remote_open_1 ()
{
(...)
/* The first packet we send to the target is the optional "supported
packets" request. If the target can answer this, it will tell us
which later probes to skip. */
remote_query_supported ();

if (non_stop && !rs->non_stop_aware)
error ("Non-stop mode requested, but remote does not support non-stop");

(...)
remote_start_remote ();
}

remote_start_remote()
{
(several checks for non_stop)
}

That is, we can't drop non-stop before connection, and only setting it
after connection after target_open returning breaks too. Events may
need to be handled before returning from target_open.

I'll either have to think more about this, or perhaps you could try it
out against a DICOS stub. ;-)

Also, if we set non-stop and it enables async + breakpoints-always-in,
plus whatnot, and then the target refuses it, do we get to revert the
async,breakpoints always-in,whatnot settings?

--
Pedro Alves