From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24070 invoked by alias); 14 Nov 2007 04:17:43 -0000 Received: (qmail 24060 invoked by uid 22791); 14 Nov 2007 04:17:42 -0000 X-Spam-Check-By: sourceware.org Received: from heller.inter.net.il (HELO heller.inter.net.il) (213.8.233.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Nov 2007 04:17:40 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-203-160.inter.net.il [80.230.203.160]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id EDA00120 (AUTH halo1); Wed, 14 Nov 2007 06:17:31 +0200 (IST) Date: Wed, 14 Nov 2007 04:17:00 -0000 Message-Id: From: Eli Zaretskii To: "Douglas Evans" CC: ghost@cs.msu.su, gdb@sources.redhat.com In-reply-to: (dje@google.com) 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/msg00120.txt.bz2 > Date: Tue, 13 Nov 2007 15:39:31 -0800 > From: "Douglas Evans" > Cc: "Vladimir Prus" , gdb@sources.redhat.com > > On Nov 13, 2007 2:18 PM, Eli Zaretskii wrote: > > > From: Vladimir Prus > > > Date: Tue, 13 Nov 2007 22:28:15 +0300 > > > > > > > (gdb) d 1.1 > > > > warning: bad breakpoint number at or near '1.1' > > > > > > Well, you can't really delete a location -- if breakpoint expression > > > corresponds to 20 addresses, that's the way it is -- you cannot delete > > > some of those addresses from the program ;-) > > > > 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? > > I think it's a question of how much complexity one wants here. AIUI, > the breakpoint is represented as source+line. One would have to > augment that to mean source+line+except-this (I think). Not necessarily. You could look up the struct bp_location that corresponds to 1.1 (by using its address as a key), and remove that struct bp_location from the chain we maintain for breakpoint 1. > Also, it's not just "delete 1.1". It's also condition, commands, and > ignore. Well, removing struct bp_location should take care of that as well. Am I missing something? > I'm not suggesting all (or any) should be supported, just that we > shouldn't tackle any of them without thinking the big picture > through at least a bit. 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.