From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17709 invoked by alias); 7 May 2007 22:27:11 -0000 Received: (qmail 17701 invoked by uid 22791); 7 May 2007 22:27:10 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 May 2007 22:27:08 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l47MR6Ox167664 for ; Mon, 7 May 2007 22:27:06 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 l47MR58G3383518 for ; Tue, 8 May 2007 00:27:06 +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 l47MR55p024936 for ; Tue, 8 May 2007 00:27:05 +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 l47MR5AZ024929 for ; Tue, 8 May 2007 00:27:05 +0200 Message-Id: <200705072227.l47MR5AZ024929@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 8 May 2007 00:27:05 +0200 Subject: [rfc] [4/4] SPU overlay support: Bugfix in remove_breakpoint To: gdb-patches@sourceware.org Date: Mon, 07 May 2007 22:27:00 -0000 From: "Ulrich Weigand" 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/msg00096.txt.bz2 Hello, this fixes a bug we discovered during SPU overlay testing. The problem occurs when remove_breakpoint attempts to remove a software breakpoint in an overlay section that is not currently mapped. The routine simply goes and writes the saved shadow contents over that location -- but if another overlay section is now mapped there, this will clobber its code. The current behaviour was introduced by Michael Snyder's patch: http://sourceware.org/ml/gdb-patches/2002-04/msg00149.html to support hardware breakpoints in overlays. And I guess if this is a hardware breakpoint, it *should* be removed -- otherwise the overlay manager would have to fiddle with hardware breakpoint registers when swapping overlays. However, for *software* breakpoints this looks definitely wrong to me. So the patch below restores the old behaviour for those: the shadow contents are restored only if the section is still mapped. Any comments? I plan on committing this after the rest of the SPU overlay support patches. Bye, Ulrich ChangeLog: * breakpoint.c (remove_breakpoint): Do not remove software breakpoints in unmapped overlay sections. diff -urNp gdb-orig/gdb/breakpoint.c gdb-head/gdb/breakpoint.c --- gdb-orig/gdb/breakpoint.c 2007-05-06 16:07:05.000000000 +0200 +++ gdb-head/gdb/breakpoint.c 2007-05-07 22:44:15.698329784 +0200 @@ -1585,8 +1585,14 @@ remove_breakpoint (struct bp_location *b don't know what the overlay manager might do. */ if (b->loc_type == bp_loc_hardware_breakpoint) val = target_remove_hw_breakpoint (&b->target_info); - else + + /* However, we should remove *software* breakpoints only + if the section is still mapped, or else we overwrite + wrong code with the saved shadow contents. */ + else if (section_is_mapped (b->section)) val = target_remove_breakpoint (&b->target_info); + else + val = 0; } else { -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com