From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18328 invoked by alias); 8 Oct 2003 17:33:25 -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 18302 invoked from network); 8 Oct 2003 17:33:23 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 8 Oct 2003 17:33:23 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h98HXLM32739 for ; Wed, 8 Oct 2003 13:33:21 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h98HXKc15471; Wed, 8 Oct 2003 13:33:21 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h98HXKpe018676; Wed, 8 Oct 2003 13:33:20 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id B21D62CC88; Wed, 8 Oct 2003 13:44:18 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16260.19698.165606.470200@localhost.redhat.com> Date: Wed, 08 Oct 2003 17:33:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, Michael Snyder Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] In-Reply-To: <20031008165534.GA8718@nevyn.them.org> References: <20031008165534.GA8718@nevyn.them.org> X-SW-Source: 2003-10/txt/msg00223.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 is certainly the right direction. We have discussed this in very general terms (I believe at the gcc conference), but I don't remember a discussion on the gdb lists. Since this seems quite a big rewrite (I am not sure, I just saw all this stuff appearing at once), how about using the branching approach? It has worked well for a few features now. elena > 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. > > 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. > > 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? > > The actual patches will follow in separate messages. Thoughts? Comments on > the overall approach? OK? > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer