From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 662 invoked by alias); 28 Apr 2008 08:02:27 -0000 Received: (qmail 608 invoked by uid 22791); 28 Apr 2008 08:02:19 -0000 X-Spam-Check-By: sourceware.org Received: from hoat.troll.no (HELO hoat.troll.no) (62.70.27.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Apr 2008 08:02:00 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id E6CB42072B for ; Mon, 28 Apr 2008 10:01:56 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id CC1482041E for ; Mon, 28 Apr 2008 10:01:56 +0200 (CEST) From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: gdb@sourceware.org Subject: Re: [MI] -break-delete with several breakpoints Date: Mon, 28 Apr 2008 17:55:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200804262208.50476.vladimir@codesourcery.com> In-Reply-To: <200804262208.50476.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804281003.38401.apoenitz@trolltech.com> 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/msg00235.txt.bz2 On Saturday 26 April 2008 20:08:50 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 would disallow it. Keep it simple ;-) > 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. I doubt it would. I could as well fire off three separate commands. As that would not require extra roundtrips, that's basically 'free'. > 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. I fully agree. Andre'