From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11134 invoked by alias); 14 Nov 2007 19:00:46 -0000 Received: (qmail 11120 invoked by uid 22791); 14 Nov 2007 19:00:42 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Nov 2007 19:00:38 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IsNTS-0006ik-8P for gdb@sources.redhat.com; Wed, 14 Nov 2007 19:00:30 +0000 Received: from 77.246.241.246 ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 19:00:30 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 19:00:30 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Multiple breakpoint locations Date: Wed, 14 Nov 2007 19:00:00 -0000 Message-ID: References: <18233.63439.953202.586908@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.4 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: 2007-11/txt/msg00141.txt.bz2 Eli Zaretskii wrote: >> From: Vladimir Prus >> Date: Wed, 14 Nov 2007 09:13:16 +0300 >> >> >> > Sorry, I don't understand why; can you please elaborate? Removing a >> >> > breakpoint instruction from a specific address is a primitive >> >> > operation of the target back-end; why can't we use it for that >> >> > single address? >> >> Because after that, the output of 'info break' will no longer correspond >> accurately to what the program is. > > I need it to correspond to the way I want the program to be stopped, > not to all possible ways a source-level locations specification can be > interpreted in terms of an address. The latter is of course a correct > starting point, but if I then chose that some of the addresses don't > make sense for me, there's no reason I should see them just for > completeness' sake. > >> > Well, my big picture is that today we have no solution for the >> > following use case: (a) I set a breakpoint that results in multiple >> > locations; (b) I look at "info break" and realize that some of these >> > locations are irrelevant for the problem I'm debugging, and I don't >> > want the program to stop there (e.g., maybe stopping there will >> > disrupt some timing); (c) I want to remove these locations from the >> > breakpoints list. >> >> You disable those locations, and gdb no longer stops there. > > That's just a workaround. The same logic could be used to argue that > there's no need to have the "delete" command at all: you can always > disable the critter. I disagree. breakpoint is something you create yourself, and it's natural you can delete something you've created. Locations exist in the program independent of you, and it's natural to be able to disable some locations. And, BTW, once you've deleted a breakpoint, you can create it afresh because you presumably remember how it was created. If you delete a location, how you recover it back? By deleting the breakpoint, creating it again, and losing enable/disable state on other unrelated locations? - Volodya