From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19088 invoked by alias); 8 Oct 2003 20:59:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19080 invoked from network); 8 Oct 2003 20:59:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 8 Oct 2003 20:59:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A7LP8-0004IU-KC for ; Wed, 08 Oct 2003 16:59:30 -0400 Date: Wed, 08 Oct 2003 20:59:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] Message-ID: <20031008205930.GA16426@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20031008165534.GA8718@nevyn.them.org> <20031008190502.GA13579@nevyn.them.org> <16260.31835.64460.668846@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16260.31835.64460.668846@localhost.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00263.txt.bz2 On Wed, Oct 08, 2003 at 05:06:35PM -0400, Elena Zannoni wrote: > Daniel Jacobowitz writes: > > > I think 'info break' should list the addresses. I don't know how this > > > should fit into the MI format, but it ought to be MI that changes, > > > rather than omitting useful behavior. > > > > > > In my ideal world, you'd get an explanation for why each address was > > > chosen, when it's not obvious: > > > > > > (gdb) info break > > > Num Type Disp Enb Address What > > > 1 breakpoint keep y 0x08048354 in foo::foo (in-charge) at hello.c:8 > > > 0x08048364 in foo::foo (not-in-charge) at hello.c:8 > > > (gdb) > > > > Here's the problem that I see. > > > > For foo::foo, there are two of these things. Having them both in the > > list would be nice. Really nice. > > > > For inline_accessor_fn there are 3.8 million. In addition to needing > > to do a whole lot of work on GDB internals before we could survive this > > (memory usage; ptrace thrashing inserting and removing them; linked > > lists of breakpoints; and that's just the beginning) this has some > > severe user interface implications. We don't want to print out all > > those addresses by default! > > > > I'm open to suggestions on how to deal with this. > > > > There is already 'maint info break', how about extending that? Would > you be able to distinguish between foo::foo breakpoints and inline > breakpoints so that they can be displayed on separate lists/commands? Hmm... sure, I suppose so. I haven't thought about how well it scales and I don't think I can until I have some implementation in front of me to play with. Something like this? 1 breakpoint keep y 0x08048354 in foo::foo() (in-charge) at hello.c:8 0x08048364 in foo::foo() (not-in-charge) at hello.c:8 2 breakpoint keep y in foo::baz at hello.c:12 3 breakpoint keep y in foo::foo(int) (in-charge) at hello.c:10 in foo::foo(int) (not-in-charge) at hello.c:10 Where the latter two describe inlined copies. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer