From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19329 invoked by alias); 5 Aug 2008 19:09:00 -0000 Received: (qmail 19314 invoked by uid 22791); 5 Aug 2008 19:08:59 -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; Tue, 05 Aug 2008 19:08:22 +0000 Received: (qmail 16774 invoked from network); 5 Aug 2008 19:08:21 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Aug 2008 19:08:21 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: [MI non-stop 06/11, RFA/RFC] Report non-stop availability, and allow to enable everything with one command. Date: Tue, 05 Aug 2008 19:09:00 -0000 User-Agent: KMail/1.9.9 Cc: Vladimir Prus , gdb-patches@sourceware.org References: <200806282054.03092.vladimir@codesourcery.com> <200808051730.53218.pedro@codesourcery.com> <20080805182735.GA7381@caradoc.them.org> In-Reply-To: <20080805182735.GA7381@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808052008.47713.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-08/txt/msg00085.txt.bz2 A Tuesday 05 August 2008 19:27:35, Daniel Jacobowitz wrote: > I can't follow all the possibilities being juggled in this > conversation. But why not just set non-stop in advance, regardless of > the target, and then issue an error at run / target remote / wherever > if non-stop is not available? Yes, that's what I've been proposing/saying we must do. Clearly, I can't express myself that well. > > We leaves some slack to add new modes like this, which would > > combine (1) and (2): > > > > set prefered-execution-mode > > "all-stop" > > prefer all-stop, but if the target doesn't support it, fine. > > "non-stop" > > prefer non-stop, but if the target doesn't support it, fine. > > "force-all-stop" > > require all-stop, fail if the target refuses it. > > "force-non-stop" > > require all-stop, fail if the target refuses it. > > Please don't, the user should know what they get. Ok, then we're back to what we have currently. I only proposed that, because Vladimir didn't like the exception/error that is currenly thrown. (In the unsubmited remote target; linux doesn't do it yet). I'll leave it to Vladimir to justify not having an error and falling back to all-stop/non-stop, if he still wants it. -- Pedro Alves