From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6950 invoked by alias); 14 Nov 2007 18:54:30 -0000 Received: (qmail 6942 invoked by uid 22791); 14 Nov 2007 18:54:29 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (213.8.233.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Nov 2007 18:54:23 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-241-37.inter.net.il [84.228.241.37]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id IID29306 (AUTH halo1); Wed, 14 Nov 2007 20:51:38 +0200 (IST) Date: Wed, 14 Nov 2007 18:54:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb@sources.redhat.com In-reply-to: (message from Vladimir Prus on Wed, 14 Nov 2007 09:13:16 +0300) Subject: Re: Multiple breakpoint locations Reply-to: Eli Zaretskii References: <18233.63439.953202.586908@kahikatea.snap.net.nz> 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/msg00140.txt.bz2 > 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.