From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25008 invoked by alias); 12 Aug 2008 13:01:20 -0000 Received: (qmail 25000 invoked by uid 22791); 12 Aug 2008 13:01:19 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Aug 2008 13:00:40 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 1D1AD98100; Tue, 12 Aug 2008 13:00:39 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id EC1C198015; Tue, 12 Aug 2008 13:00:38 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KStUM-0008MB-Ax; Tue, 12 Aug 2008 09:00:38 -0400 Date: Tue, 12 Aug 2008 13:01:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [MI non-stop 06/11, RFA/RFC] Report non-stop availability, and allow to enable everything with one command. Message-ID: <20080812130038.GA32105@caradoc.them.org> Mail-Followup-To: Vladimir Prus , Pedro Alves , gdb-patches@sourceware.org References: <200806282054.03092.vladimir@codesourcery.com> <200808121009.11540.vladimir@codesourcery.com> <20080812120835.GA29188@caradoc.them.org> <200808121646.38779.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808121646.38779.vladimir@codesourcery.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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/msg00314.txt.bz2 On Tue, Aug 12, 2008 at 04:46:38PM +0400, Vladimir Prus wrote: > On Tuesday 12 August 2008 16:08:35 Daniel Jacobowitz wrote: > > On Tue, Aug 12, 2008 at 10:09:11AM +0400, Vladimir Prus wrote: > > > 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. > > > > Actually I think this is very unintuitive. You'll have to know > > whether you get non-stop or not because commands act very differently > > between all-stop and non-stop. Scripts written for the one won't work > > with the other, for example. > > Yes, you have to know whether you get non-stop or not -- does this contradict > to anything I've said? Yes. If enabling non-stop means "I prefer non-stop" then every script and front end has to query "I asked for non-stop but did I really get it?" and the user has to be paying attention to GDB's messages. I don't think that's a good idea. This is mostly a problem for the testsuite. Non-stop will be awesome and useful so the targets where people want it, it'll get implemented :-) -- Daniel Jacobowitz CodeSourcery