From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18405 invoked by alias); 16 Oct 2003 16:16:37 -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 18395 invoked from network); 16 Oct 2003 16:16:36 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Oct 2003 16:16:36 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AAAnj-0005P0-PD for ; Thu, 16 Oct 2003 12:16:35 -0400 Date: Thu, 16 Oct 2003 16:16:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8] Message-ID: <20031016161635.GA20667@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <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> <6654-Thu16Oct2003085007+0200-eliz@elta.co.il> <3F8EAA56.3020900@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8EAA56.3020900@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00548.txt.bz2 On Thu, Oct 16, 2003 at 10:25:26AM -0400, Andrew Cagney wrote: > >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. > > BTW, long term, this stuff is going to be hijacked by other *point > mechanisms. Variable watchpoints, for instance, will be given a similar > projection (the watchpoint changes that last year stalled can probably > be picked up again). While the term "breakpoint" may continue to be > used, it will be applied to more than just breakpoints. Shorter term than you may think :) My plan now is something like this: - Cleanup patches, as posted - Internal support for multiple locations per breakpoint - Adapt watchpoints to use the multiple locations support, which will be rather cleaner than what we have now. - Then move on to fun stuff with breakpoints. Could you give me a pointer to the watchpoint changes you're talking about? I don't recall them. > PS: To make everyone feel ill - logical_debugpoint, physical_debugpoint ... That's the concept, but I don't think we have a real problem with continuing to overload breakpoint for that. Consider "info break". -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer