From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31204 invoked by alias); 28 Apr 2007 21:45:15 -0000 Received: (qmail 31190 invoked by uid 22791); 28 Apr 2007 21:45:15 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 28 Apr 2007 22:45:13 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 987694B267; Sat, 28 Apr 2007 16:45:11 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 5C1304B262; Sat, 28 Apr 2007 16:45:11 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1Hhuj8-0003Ei-Ny; Sat, 28 Apr 2007 17:45:10 -0400 Date: Sat, 28 Apr 2007 21:54:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] Set a breakpoint's type before adjusting its address Message-ID: <20070428214510.GA12239@caradoc.them.org> Mail-Followup-To: Kevin Buettner , gdb-patches@sources.redhat.com References: <20070427151559.0394bfa0@ironwood.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070427151559.0394bfa0@ironwood.lan> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00383.txt.bz2 On Fri, Apr 27, 2007 at 03:15:59PM -0700, Kevin Buettner wrote: > At the moment, running GDB on an FR-V target will generate lots of > "reading through apparently deleted breakpoint" warnings. This is due > to the fact that (due to architectural constraints) FR-V needs to > adjust breakpoint addresses. When it does so, it reads through > read_memory_nobpt(), triggering the warning due to the fact that the > breakpoint's type hasn't been set yet. The patch below moves the type > assignment prior to the adjustment thus avoiding this situation. > > Comments? > > * breakpoint.c (set_raw_breakpoint): Set breakpoint type before > attempting to adjust its address. This happens because the breakpoint's location is already on the location chain, right? Alternatively, we could move that from the end of allocate_bp_location to the end of set_raw_breakpoint, and avoid the inconsistency. -- Daniel Jacobowitz CodeSourcery