From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12889 invoked by alias); 26 Apr 2008 19:49:28 -0000 Received: (qmail 12878 invoked by uid 22791); 26 Apr 2008 19:49:27 -0000 X-Spam-Check-By: sourceware.org Received: from vms044pub.verizon.net (HELO vms044pub.verizon.net) (206.46.252.44) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Apr 2008 19:49:08 +0000 Received: from black ([71.245.67.80]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JZY00J1J71864M2@vms044.mailsrvcs.net> for gdb@sourceware.org; Sat, 26 Apr 2008 14:48:44 -0500 (CDT) Received: from bob by black with local (Exim 4.67) (envelope-from ) id 1JpqO3-00042q-Vo; Sat, 26 Apr 2008 15:48:43 -0400 Date: Sat, 26 Apr 2008 22:23:00 -0000 From: Bob Rossi Subject: Re: [MI] -break-delete with several breakpoints In-reply-to: <200804262208.50476.vladimir@codesourcery.com> To: Vladimir Prus Cc: gdb@sourceware.org Message-id: <20080426194843.GA13338@brasko.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline References: <200804262208.50476.vladimir@codesourcery.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00215.txt.bz2 On Sat, Apr 26, 2008 at 10:08:50PM +0400, Vladimir Prus wrote: > > I've noticed that right now, both -break-delete and -break-disable > commands accept several breakpoint ids, like: > > -break-disable 1 2 3 > > This behaviour comes almost by accident, and is not documented anywhere. > The question is -- should we document it and add tests, or should we > declare this behaviour does not exist? > > I think that most of the time, making use of this behaviour will require > explicit code in the frontend, and the question is if that makes sense. > Say, for -var-update accepting a list of variable object might be good idea, > since the number of variable object can be significant, and they are updated > on each step. For deleting and disabling breakpoints, I'm actually not sure. > Typically, there are few breakpoints and wholesale delete is not common, > so it's not worth optimizing for. > > Opinions? The only case I can think that would be nice is something like, -break-disable -all Bob Rossi