From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23132 invoked by alias); 12 Aug 2008 06:10:00 -0000 Received: (qmail 23123 invoked by uid 22791); 12 Aug 2008 06:10:00 -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, 12 Aug 2008 06:09:25 +0000 Received: (qmail 28380 invoked from network); 12 Aug 2008 06:09:23 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Aug 2008 06:09:23 -0000 From: Vladimir Prus To: Pedro Alves Subject: Re: [MI non-stop 06/11, RFA/RFC] Report non-stop availability, and allow to enable everything with one command. Date: Tue, 12 Aug 2008 06:10:00 -0000 User-Agent: KMail/1.9.9 Cc: Daniel Jacobowitz , gdb-patches@sourceware.org References: <200806282054.03092.vladimir@codesourcery.com> <20080805182735.GA7381@caradoc.them.org> <200808052008.47713.pedro@codesourcery.com> In-Reply-To: <200808052008.47713.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808121009.11540.vladimir@codesourcery.com> 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/msg00310.txt.bz2 On Tuesday 05 August 2008 23:08:46 Pedro Alves wrote: > 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. My motivation was that the most intuitive model is that of immediate application of non-stop flag, with error produced immediately. This is hard to implement. Next most intuitive model is "I prefer non-stop mode", which is what I propose. The model where 'non-stop' variable is a hard request, but the error is delayed seems fairly unconventional to me. - Volodya