From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21682 invoked by alias); 15 Oct 2003 22:41:36 -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 21659 invoked from network); 15 Oct 2003 22:41:35 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 15 Oct 2003 22:41:35 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1A9uKk-0001Y5-Hy for ; Wed, 15 Oct 2003 18:41:34 -0400 Date: Wed, 15 Oct 2003 22:41:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] Message-ID: <20031015224134.GA4102@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20031008165534.GA8718@nevyn.them.org> <20031008190502.GA13579@nevyn.them.org> <3F846B04.2070801@redhat.com> <3F85B4AC.7000000@redhat.com> <20031014013831.GB6118@nevyn.them.org> <3F8C18DD.3020508@redhat.com> <20031014155126.GA10669@nevyn.them.org> <3F8C605E.1060604@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8C605E.1060604@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00522.txt.bz2 On Tue, Oct 14, 2003 at 01:45:18PM -0700, Michael Snyder wrote: > I don't think any of those pairs would convey at first glance > what the distinction is, to an average user (I hesitated to > say "naive"). With your or my knowledge of debugger internals, > we might look at almost any of those and figure out what they > mean, but ask someone who doesn't know what a register is... > > If this is just an internals issue, then toss a coin, it > doesn't matter. But for the picture that we present to the > user, remember -- we always present a fictional picture that > hides most of the underlying details. The unsophisticated > user thinks he is debugging his code -- not the underlying > machine. If possible, he doesn't want to know eg. that > line seventeen has been broken into several locations and > intermixed with code from 3 other lines. We're sometimes > forced to tell him anyway, but we don't if we can avoid it. > > From that perspective, I think a breakpoint is a breakpoint. > To the user it represents a location in the *source* code. > The fact that this may translate to several locations in > the machine code is "under the hood", so to speak. If he > wants that level of information, we should give it to him, > but maybe the metaphor should reflect the fact that this is > "what's inside the box", as opposed to, like, two different > kinds of breakpoint (virtual/actual or whatever). So for > instance, we might say that *this* is the breakpoint, and > if you want to know, *these* are the breakpoint's *locations*. > > There -- you asked for my opinion. Are you happy? ;-) Quite happy :) This suggests struct breakpoint and struct bp_location (or maybe even bp_element, which is clearer for watchpoints, but less clear overall). For this approach, I see: Pro: it's much clearer. Con: it gives breakpoint two meanings in the internals documentation; the target sets a breakpoint according to a bp_location; a struct breakpoint can cause the target to set many breakpoints. But I think that if we have to be confused somewhere, that's the place to put the confusion. Do others like this? I have a couple of other flagged messages to respond to in this thread, but they all seem to have moved onto the general multi-breakpoints problem. Michael, once we're agreed on a name could you review the cleanup patches? Then I'll put together a branch for the interesting bits. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer