From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30336 invoked by alias); 8 Oct 2003 18:07:00 -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 30320 invoked from network); 8 Oct 2003 18:06:59 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 8 Oct 2003 18:06:59 -0000 Received: by zenia.home (Postfix, from userid 5433) id 6B1CF20766; Wed, 8 Oct 2003 13:05:34 -0500 (EST) To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, Michael Snyder Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] References: <20031008165534.GA8718@nevyn.them.org> From: Jim Blandy Date: Wed, 08 Oct 2003 18:07:00 -0000 In-Reply-To: <20031008165534.GA8718@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00228.txt.bz2 Daniel Jacobowitz writes: > This is a series of eight patches which begin to clean up our infrastructure > for tracking breakpoints. More specifically, I chose to split the struct > breakpoint into two: one which is logically associated with the user's > "break" command, and one which is logically associated with an insertable > breakpoint. The general idea is that the mapping should be one-to-many > eventually. Right now it isn't and there's a long way to go before we can > get there, but this is a first step. > > This will make it simpler to have, for instance, a breakpoint on both the > in-charge and not-in-charge constructors without bothering the user with > that detail. Similarly (eventually!) for copies of an inlined function, or > multiple copies of an executed line. This is a bit of a ways in the future > but I'm working on it. This sounds really great. When you think about what actually is happening in the debuggee, the mapping is actually many-to-many, since you can have multiple user breakpoints at the same address. Not that this affects your data structures --- just an observation. > On the infrastructure side we will be able to have an "impl_breakpoint" > (short for implementation; better naming ideas?) for each location we are > watching using hardware watchpoints. This will simplify a lot of code. It > will also eventually become easier to object-orient our breakpoints. How about "user breakpoints" and "machine breakpoints"? > Except for a couple of minor bug fixes where noted, these patches change > nothing. They use the assumption that every breakpoint has exactly one > implementation breakpoint. After they've been applied, it's easy to find > conceptual layering issues; most (not all) references to b->impl are > potential problems, and some references to bpt->owner are also. I've > converted functions which operated primarily on the impl to accept impl > breakpoint arguments instead of user breakpoint arguments. Many of the > remaining layering issus deal with printing the address of a breakpoint; I'd > love to hear what other people think we should do for breakpoints with > multiple addresses. Just say multiple, and provide a maint (or info) > command to look at them? 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)