From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16597 invoked by alias); 14 Jan 2006 16:16:46 -0000 Received: (qmail 16428 invoked by uid 22791); 14 Jan 2006 16:16:45 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 14 Jan 2006 16:16:43 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Exo52-0003Mh-Sq; Sat, 14 Jan 2006 11:16:40 -0500 Date: Sat, 14 Jan 2006 16:16:00 -0000 From: Daniel Jacobowitz To: Paul Hilfinger Cc: gdb@sourceware.org Subject: Re: [RFC] multiple breakpoints from FILE:LINE Message-ID: <20060114161640.GA12796@nevyn.them.org> Mail-Followup-To: Paul Hilfinger , gdb@sourceware.org References: <20060113104212.0B28848CBD8@nile.gnat.com> <20060113152350.GA9758@nevyn.them.org> <20060114101507.7C5F048CBD6@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060114101507.7C5F048CBD6@nile.gnat.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00116.txt.bz2 On Sat, Jan 14, 2006 at 05:15:07AM -0500, Paul Hilfinger wrote: > > > We have discussed this issue many times in the past, as recently as two > > weeks ago. In the beginning of 2005 I posted a prototype patch to set > > only a single breakpoint, but associate it with multiple locations. I > > still firmly believe that that is the correct solution. However, the > > patch was never finished. > > [The patch Daniel refers to here, by the way, is > > http://sources.redhat.com/ml/gdb-patches/2005-03/msg00195.html] > > What led you to conclude that you wouldn't need the ability to set (or > delete) only SOME breakpoints corresponding to a given location (i.e., > some number greater than, say, 2 and less than all)? I can see one possible > reason: since the 'command' and 'condition' commands do not take > BP ranges, it is difficult to apply them to lots of breakpoints. On the > other hand, one could extend these commands to allow a range of breakpoints > rather than a single breakpoint. But then on the third hand (first foot?), > the implementation would require some annoying manipulations to avoid > double freeing (of expressions or command sequences) or other atrocities. Just to be clear, there's no "range of breakpoints" concept in my solution. You get a single breakpoint, say, breakpoint number 2, which corresponds to twenty occurances of some inlined function. I have no objection to commands for finer grained modification of breakpoints. But they're going to be tricky to get right, because in this new system I want to always keep some hard problems in mind. For example, preserving the enable state of breakpoints sensibly over a recompiled and reloaded application. If you've got "break foo.c:20" and suddenly there's a new instance of it and it maps to 21 breakpoints instead of 20, that's good. If you've somehow said "disable 2 location 4" to disable just one of those twenty breakpoints, and now there are 21 instead of 20, you need to figure out which one's been disabled by the user! > > Those menus have got to go. They're (a) confusing to users (in my > > opinion, no real data), and (b) extremely awkward for graphical > > frontends. > > Interesting. As I said, in Ada, the multi-line feature is much more > important than in C. AdaCore's version has been around for years, and > has simply created multiple breakpoints (controlled by menu, as for > overloading). We haven't gotten loud calls for doing things > differently (well, point (b) has caused internal gripes), but perhaps I > should do some polling for soft grumbling from users. >From what I've seen, in GNAT (a) is less likely to be true. In any system where the compiler is likely to produce copies of a function without clear explanation to the user, it's much more confusing. GCC will surely do this soon, e.g. for interprocedural constant propagation. -- Daniel Jacobowitz CodeSourcery