From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3421 invoked by alias); 14 Nov 2007 06:13:49 -0000 Received: (qmail 3412 invoked by uid 22791); 14 Nov 2007 06:13:48 -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 06:13:43 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IsBVE-0001pC-Pn for gdb@sources.redhat.com; Wed, 14 Nov 2007 06:13:32 +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 06:13:32 +0000 Received: from ghost by 77.246.241.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 06:13:32 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Multiple breakpoint locations Date: Wed, 14 Nov 2007 06:13: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/msg00122.txt.bz2 Eli Zaretskii wrote: >> 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? Because after that, the output of 'info break' will no longer correspond accurately to what the program is. If there are 20 locations in program, and 'info break' shows 20 locations, it means the user sees *all* locations. He can disable some of them, and then he'll see that some of locations are disabled. If you allow removing a location, it means the list of location starts to show all locations except for previously removed ones, and there's no way to investigate which removed locations were there, how many are removed and so on. It seems to be that disabling undesired locations is more transparent approach. >> 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. You disable those locations, and gdb no longer stops there. And GDB, furthermore, will try hard to keep those locations disabled as shared libraries are loaded and unloaded. - Volodya