From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8517 invoked by alias); 11 Dec 2003 20:36:06 -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 8410 invoked from network); 11 Dec 2003 20:36:04 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 11 Dec 2003 20:36:04 -0000 Received: by zenia.home (Postfix, from userid 5433) id 3111520766; Thu, 11 Dec 2003 15:33:35 -0500 (EST) To: Daniel Jacobowitz Cc: Eli Zaretskii , Jeff Johnston , gdb-patches@sources.redhat.com Subject: Re: [RFA]: breakpoint.c patch (prelude to pending breakpoint support) References: <3FD7C458.2080404@redhat.com> <20031211142119.GA26428@nevyn.them.org> From: Jim Blandy Date: Thu, 11 Dec 2003 20:36:00 -0000 In-Reply-To: <20031211142119.GA26428@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-12/txt/msg00325.txt.bz2 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.