From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5756 invoked by alias); 28 Mar 2003 23:56:42 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5748 invoked from network); 28 Mar 2003 23:56:41 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 28 Mar 2003 23:56:41 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18z5bh-0005Uk-00; Fri, 28 Mar 2003 19:58:05 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18z3i6-0001ZK-00; Fri, 28 Mar 2003 18:56:34 -0500 Date: Fri, 28 Mar 2003 23:56:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jim Ingham , gdb@sources.redhat.com Subject: Re: gdb Digest 26 Mar 2003 19:03:48 -0000 Issue 1129 Message-ID: <20030328235634.GA5920@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jim Ingham , gdb@sources.redhat.com References: <672C9F08-5FC2-11D7-B2F4-00039379E320@apple.com> <3E84D16F.5020304@redhat.com> <3E84D706.3060708@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E84D706.3060708@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00397.txt.bz2 On Fri, Mar 28, 2003 at 06:13:10PM -0500, Andrew Cagney wrote: > >>Andrew, > >> > >>Addressing this problem - driven by the needs of C++ developers - is > >>something I was lobbying for time to do during this release cycle. But > >>it got put off in favor of solving performance issues in gdb instead. > >>However, for the next one (starting post June) release cycle I will > >>probably get more time to look at this. > >> > >>I don't think we can just hide the physical breakpoints from the user > >>however. It would be very useful to be able to say > >> > >>(gdb) break FileFullOfTemplates.cc:27 > >> > >>then decide that "no you weren't interested in the int specialization > >>only the double one", or whatever... So being able to peer into the > >>contents of the user-lever breakpoint is a good thing. OTOH, I should > >>certainly be able to disable this breakpoint and not hit it for any > >>variant... > >> > > >True. Being able to manipulate the mapping will also be useful. > > brain enganges. It's more complicated. If I understand this correctly. > > (gdb) break FileFullOfTemplates.hh:27 > > The user might mean: > > - the line number > - a template instance > - all inline function instances > - (I'm sure there is more) Right. The big thing this means is that we need to think about the interface. Asking isn't a real option. For instance, in the Linux kernel, if you break on (say) i386's inlined get_current function - if we could ever handle that - there'd probably be millions of locations. This requires: - scaling the implementation; if we remove a million breakpoints at every stop then we're going to lose. - scaling the interface; if we ask a million questions the user will give up. > Either way, I think these are high-level table entries. The user could > certainly view the mapping: > > maint print breakpoint > Breakpoint 1