From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1765 invoked by alias); 14 Oct 2003 01:30: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 1756 invoked from network); 14 Oct 2003 01:29:59 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 14 Oct 2003 01:29:59 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1A9E0c-0001bA-5U for ; Mon, 13 Oct 2003 21:29:58 -0400 Date: Tue, 14 Oct 2003 01:30:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [1/8] - define impl_breakpoint Message-ID: <20031014012958.GA6118@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20031008170233.GA9013@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00437.txt.bz2 On Wed, Oct 08, 2003 at 01:16:03PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > +/* GDB maintains two groups of breakpoints and related events. One > > + group are the "implementation breakpoints"; these are minimal > > + structures used to manage stopping the program. They map to a specific > > + stop reason (trap at a particular PC, for instance). The other group > > + are "user breakpoints"; these carry higher-level information including > > + source locations and breakpoint conditions. */ > > "minimal structures used to manage stopping the program" could be > almost anything. How about: > > GDB maintains two groups of breakpoints and related events. One > group are the "implementation breakpoints" (struct > impl_breakpoint); these represent specific machine-level > mechanisms used to stop the program: trap instructions patched > into the code ("software breakpoints"), hardware breakpoints, > hardware watchpoint registers, and so on. > > The other group are "user breakpoints" (struct breakpoint); these > are the breakpoints as seen and manipulated by the user. They > carry higher-level information like source locations and > breakpoint conditions. > > A single user breakpoint may use several implementation > breakpoints to get the right effect. For example, the GNU C++ > compiler emits two copies of each constructor: the 'in-charge' > constructor and the 'not-in-charge' constructor. So a user > breakpoint on the constructor would have two separate > implementation breakpoints, one for each copy. Thanks, I like it. I'll adapt it into the next version. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer