From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3007 invoked by alias); 11 May 2007 18:55:15 -0000 Received: (qmail 2996 invoked by uid 22791); 11 May 2007 18:55:14 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate8.de.ibm.com (HELO mtagate8.de.ibm.com) (195.212.29.157) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 May 2007 18:55:11 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id l4BIt8Jj286718 for ; Fri, 11 May 2007 18:55:08 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l4BIt8jB4141118 for ; Fri, 11 May 2007 20:55:08 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l4BIt8pM016689 for ; Fri, 11 May 2007 20:55:08 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l4BIt8oB016684; Fri, 11 May 2007 20:55:08 +0200 Message-Id: <200705111855.l4BIt8oB016684@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 11 May 2007 20:55:08 +0200 Subject: Re: [rfc] [4/4] SPU overlay support: Bugfix in remove_breakpoint To: drow@false.org (Daniel Jacobowitz) Date: Fri, 11 May 2007 18:55:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20070511172943.GB22529@caradoc.them.org> from "Daniel Jacobowitz" at May 11, 2007 01:29:43 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-05/txt/msg00205.txt.bz2 Daniel Jacobowitz wrote: > On Fri, May 11, 2007 at 12:05:45AM +0200, Ulrich Weigand wrote: > > The way to handle read-write overlay managers is to arrange for > > the LMA to point to the backing-store RAM address where the > > overlay has been swapped to, and remove the swapped-out breakpoint > > at the *LMA* address. The existing code already handles that > > correctly (assuming overlay_events_enabled is false, as it should > > be for read-write overlay managers). > > I followed you right up until the end. Why should > overlay_events_enabled be false for read-write overlay management? > > We could still be using hardware breakpoints (for example) with > RAM-based overlays. We'd want notification events so that we could > enable or disable the hardware breakpoint appropriately. OK, I didn't consider that case. Well, that's not supported right now -- common code does not actually *know* whether the overlay manager is read-only or read-write, it simply infers that from whether or not we have event notification. If we want to support read-write overlays with both hardware and software breakpoints, we'd need to make common code aware that the target does support writing to the breakpoint LMA, and handle software breakpoint as follows: - To install, always set breakpoint at the LMA; and if mapped, set it also at the VMA. - To remove, always remove breakpoint at the LMA; and if mapped, remove it also at the VMA. In any case, removing a software breakpoint at the VMA in an unmapped section would still be wrong ... I guess we can implement that once we have a target that actually supports this particular overlay mode. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com