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

[Pedro Alves <pedro@codesourcery.com>]

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