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 Monday 28 July 2008 21:57:48 Pedro Alves wrote:
> 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.

The question is why the connection setup needs to know if we're in non-stop,
and why -- which question we discuss below.

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

I think we can implement a scheme where a target say it does not know
if non-stop is supported until connecting, and have the target set non_stop
to zero if it's actually not supported. Something like probing for packets
in remote protocol.

> (*) 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.

Well, if that might change then probably (2) is the right approach, and we should
wait for your changes to land?
 
> > 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)  
>  }

Or maybe not -- the logic in remote_start_remote seems not very trivial.
 
> 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.  ;-)

I surely can try it against a DICOS stub -- but it's not clear what to 
try :-) 

Basically, from the point of frontend we need a way to say that non-stop,
and async, are desired, and to understand if that request is respected.
Whether frontend sets 'non-stop' to 1 after 'target remote' and gets the
error immediately, or sets it to 1 before target remote, and later queries
if non-stop is actually enabled, is not very important. However, the behaviour
of non-stop and of various ways to enable async should be consistent, I think.

That is, the options are:

1. We do

    set non-stop 1
    set async 1
    target remote xxx

and if the target does not support either non-stop, or async, we get error.

2. We do:

    set non-stop 1
    set async 1
    target remote xxx

and if the target does not support either non-stop or async, we'll operate
in all-stop, or sync more, respectively. There will be some way to check if
we're really in non-stop, or async, mode.

3. We do:

    target remote xxxx
    set non-stop 1
    set async 1

and then if non-stop or async is not supported, we get an error from the "set"
command. 

For (3), the question is what to do if we send another "target XXX" command. Should
we reset both variables, or should we do either (1) or (2). For (1) I don't like
the hard error -- if the frontend really demands non-stop mode, it can always bark
itself. So, I think (2) is best. OTOH, it's not how non-stop mode works now --
remote will error out if non stop is not supported by the stub, so we'd have to split
non_stop into non_stop_requested and non_stop_actually_enabled, which is mechanical,
but big change. What do you think is best here?

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

Well, I now think individual toggles are better -- with non-stop mode checking
if async and breakpoints-always-inserted are on. This way, if we can't enable
non-stop, the frontend is in control of whether the others two should still
be enabled.

- Volodya