From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9598 invoked by alias); 12 Dec 2003 02:51:41 -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 9591 invoked from network); 12 Dec 2003 02:51:41 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 12 Dec 2003 02:51:41 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AUdP1-0003LW-Ej; Thu, 11 Dec 2003 21:51:39 -0500 Date: Fri, 12 Dec 2003 02:51:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Eli Zaretskii , Jeff Johnston , gdb-patches@sources.redhat.com Subject: Re: [RFA]: breakpoint.c patch (prelude to pending breakpoint support) Message-ID: <20031212025139.GA12806@nevyn.them.org> Mail-Followup-To: Jim Blandy , Eli Zaretskii , Jeff Johnston , gdb-patches@sources.redhat.com References: <3FD7C458.2080404@redhat.com> <20031211142119.GA26428@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-12/txt/msg00327.txt.bz2 On Thu, Dec 11, 2003 at 03:33:34PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > Right now, there are five possible enable states: > > enabled > > disabled > > permanent > > call_disabled > > shlib_disabled > > > > I'm not convinced that permanent should even be on the list. It's a > > real oddball; and there's no reason that GDB couldn't virtually > > "disable" a permanent breakpoint (step over it automatically when > > hitting it; give it an always-false condition, in effect). > > I'm responsible for adding the permanent breakpoint kludge. > > Permanent breakpoints were added for HP-UX, where the dynamic linker > lives in a special region of memory that the debugger cannot modify. > The breakpoint instruction is hard-coded into the function; and GDB > cannot write to that address to remove it. pa64solib.c seems to be > the only code that creates them. > > In an earlier message, you said: > > It's not clear what to do with permanent breakpoints (I don't think > > that should be an enable state, long term!) so I chose the version > > with minimal textual changes. > > Do you mean, here, that having breakpoint_enabled return false for > permanent breakpoints results in fewer changes overall? I would > expect the opposite --- permanent breakpoints really are enabled. Yes, but most code either: - Doesn't know about permanent breakpoints or - Doesn't want to deal with permanent breakpoints Take a look at the patch Jeff posted yesterday for breakpoint.c to see how this happens. I suspect it's mostly the former; if you wanted to add permanent breakpoints to breakpoint_enabled() you'd have to review all its callers to see the effect (which would be easier now). -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer