From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15629 invoked by alias); 14 Jan 2006 10:15:12 -0000 Received: (qmail 15616 invoked by uid 22791); 14 Jan 2006 10:15:11 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 14 Jan 2006 10:15:10 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id A012A48CE1D; Sat, 14 Jan 2006 05:15:07 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07809-02-2; Sat, 14 Jan 2006 05:15:07 -0500 (EST) Received: by nile.gnat.com (Postfix, from userid 1345) id 7C5F048CBD6; Sat, 14 Jan 2006 05:15:07 -0500 (EST) From: Paul Hilfinger To: drow@false.org CC: gdb@sourceware.org In-reply-to: <20060113152350.GA9758@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 13 Jan 2006 10:23:51 -0500) Subject: Re: [RFC] multiple breakpoints from FILE:LINE References: <20060113104212.0B28848CBD8@nile.gnat.com> <20060113152350.GA9758@nevyn.them.org> Message-Id: <20060114101507.7C5F048CBD6@nile.gnat.com> Date: Sat, 14 Jan 2006 10:15:00 -0000 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/msg00115.txt.bz2 > 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. > 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. Paul Hilfinger