From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26096 invoked by alias); 16 Oct 2003 06:55:10 -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 26089 invoked from network); 16 Oct 2003 06:55:09 -0000 Received: from unknown (HELO bilbo.inter.net.il) (192.114.186.18) by sources.redhat.com with SMTP; 16 Oct 2003 06:55:09 -0000 Received: from zaretski ([80.230.156.210]) by bilbo.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id BQP62046; Thu, 16 Oct 2003 08:54:33 +0200 (IST) Date: Thu, 16 Oct 2003 06:55:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-Id: <6654-Thu16Oct2003085007+0200-eliz@elta.co.il> CC: gdb-patches@sources.redhat.com In-reply-to: <20031015224134.GA4102@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 15 Oct 2003 18:41:34 -0400) Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] Reply-to: Eli Zaretskii 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> <20031015224134.GA4102@nevyn.them.org> X-SW-Source: 2003-10/txt/msg00535.txt.bz2 > Date: Wed, 15 Oct 2003 18:41:34 -0400 > From: Daniel Jacobowitz > > > > 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 I'm with Michael here. You might recall that I originally suggested to call those impl_breakpoint's just ``locations'' or ``addresses'' of a particular breakpoint. If ``location'' is not good enough (after all, there's other information stored about each address, like the kind of trap we set there), let's use some more vague word, like bp_spot or maybe bp_instance. > 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. That's just a choice of words that confuses you. I suggest a different choice of words: the target sets a breakpoint according information in bp_location; a struct breakpoint can cause a target to set the breakpoint in several locations (or at several addresses).