From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15661 invoked by alias); 28 Jul 2008 17:58:20 -0000 Received: (qmail 15643 invoked by uid 22791); 28 Jul 2008 17:58:19 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Jul 2008 17:58:02 +0000 Received: (qmail 30745 invoked from network); 28 Jul 2008 17:58:00 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Jul 2008 17:58:00 -0000 From: Pedro Alves To: Vladimir Prus Subject: Re: [MI non-stop 06/11, RFA/RFC] Report non-stop availability, and allow to enable everything with one command. Date: Mon, 28 Jul 2008 17:58:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org References: <200806282054.03092.vladimir@codesourcery.com> <200807111434.18119.pedro@codesourcery.com> <200807231148.27184.vladimir@codesourcery.com> In-Reply-To: <200807231148.27184.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807281857.49206.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00524.txt.bz2 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