From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16538 invoked by alias); 28 Apr 2008 20:09:18 -0000 Received: (qmail 16526 invoked by uid 22791); 28 Apr 2008 20:09:17 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Apr 2008 20:09:00 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id EF53C3C313; Mon, 28 Apr 2008 13:08:58 -0700 (PDT) Subject: Re: [MI] -break-delete with several breakpoints From: Michael Snyder To: Vladimir Prus Cc: gdb@sourceware.org In-Reply-To: <200804262208.50476.vladimir@codesourcery.com> References: <200804262208.50476.vladimir@codesourcery.com> Content-Type: text/plain Date: Tue, 29 Apr 2008 18:51:00 -0000 Message-Id: <1209413338.4615.307.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit 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/msg00246.txt.bz2 On Sat, 2008-04-26 at 22:08 +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? I'm guessing that this is an artifact of the fact that the CLI commands (break, delete, enable, disable...) are all willing to accept this type of argument list.