From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3383 invoked by alias); 8 Oct 2003 18:17:29 -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 3376 invoked from network); 8 Oct 2003 18:17:28 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 8 Oct 2003 18:17:28 -0000 Received: by zenia.home (Postfix, from userid 5433) id 678B220766; Wed, 8 Oct 2003 13:16:03 -0500 (EST) To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [1/8] - define impl_breakpoint References: <20031008170233.GA9013@nevyn.them.org> From: Jim Blandy Date: Wed, 08 Oct 2003 18:17:00 -0000 In-Reply-To: <20031008170233.GA9013@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/msg00229.txt.bz2 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.