From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24688 invoked by alias); 8 Oct 2003 16:55:35 -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 24651 invoked from network); 8 Oct 2003 16:55:34 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 8 Oct 2003 16:55:34 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A7Hb4-0002LB-3p; Wed, 08 Oct 2003 12:55:34 -0400 Date: Wed, 08 Oct 2003 16:55:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Cc: Michael Snyder Subject: RFA: Breakpoint infrastructure cleanups [0/8] Message-ID: <20031008165534.GA8718@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com, Michael Snyder Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00213.txt.bz2 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. 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