From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25943 invoked by alias); 3 Nov 2006 17:58:49 -0000 Received: (qmail 25930 invoked by uid 22791); 3 Nov 2006 17:58:47 -0000 X-Spam-Check-By: sourceware.org Received: from e1.ny.us.ibm.com (HELO e1.ny.us.ibm.com) (32.97.182.141) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Nov 2006 17:58:38 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kA3HwXRR001982 for ; Fri, 3 Nov 2006 12:58:33 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kA3HwXll275398 for ; Fri, 3 Nov 2006 12:58:33 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kA3HwNOj003656 for ; Fri, 3 Nov 2006 12:58:23 -0500 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kA3HwNXL002822; Fri, 3 Nov 2006 12:58:23 -0500 Subject: Re: patch: signal trampoline frame cache corruption (repost?) From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: Mark Kettenis Cc: gdb-patches@sourceware.org In-Reply-To: <200610312328.k9VNScRC012608@elgar.sibelius.xs4all.nl> References: <1162323227.3428.9.camel@dufur.beaverton.ibm.com> <200610312328.k9VNScRC012608@elgar.sibelius.xs4all.nl> Content-Type: multipart/mixed; boundary="=-tsReUJzaVnXMYaAwk+tQ" Date: Fri, 03 Nov 2006 17:58:00 -0000 Message-Id: <1162576236.3428.17.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00021.txt.bz2 --=-tsReUJzaVnXMYaAwk+tQ Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 411 On Wed, 2006-11-01 at 00:28 +0100, Mark Kettenis wrote: > > . . . > > Ok to commit? (This is almost an obvious fix, isn't it?) > > Not as you've posted it, since it doesn't adhere to the GNU coding > style. But the idea seems alright to me. > > Mark Ufda! Sorry about the formatting. I fixed that, and included a ChangeLog entry which I also forgot the first time. Now is it OK to commit? -=# Paul #=- --=-tsReUJzaVnXMYaAwk+tQ Content-Disposition: attachment; filename=fix-sigtramp-cache.patch Content-Type: text/x-patch; name=fix-sigtramp-cache.patch; charset=utf-8 Content-Transfer-Encoding: 7bit Content-length: 1381 2006-11-03 Paul Gilliam * ppc-linux-tdep.c (ppc_linux_sigtramp_cache): Only deal with the floating point registers if the processor has a floating point unit. Index: ppc-linux-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v retrieving revision 1.78 diff -a -u -r1.78 ppc-linux-tdep.c --- ppc-linux-tdep.c 18 Apr 2006 19:20:06 -0000 1.78 +++ ppc-linux-tdep.c 3 Nov 2006 17:45:28 -0000 @@ -916,14 +916,18 @@ trad_frame_set_reg_addr (this_cache, tdep->ppc_cr_regnum, gpregs + 38 * tdep->wordsize); - /* Floating point registers. */ - for (i = 0; i < 32; i++) + if (ppc_floating_point_unit_p(gdbarch)) { - int regnum = i + FP0_REGNUM; - trad_frame_set_reg_addr (this_cache, regnum, fpregs + i * tdep->wordsize); + /* Floating point registers. */ + for (i = 0; i < 32; i++) + { + int regnum = i + FP0_REGNUM; + trad_frame_set_reg_addr (this_cache, regnum, + fpregs + i * tdep->wordsize); + } + trad_frame_set_reg_addr (this_cache, tdep->ppc_fpscr_regnum, + fpregs + 32 * tdep->wordsize); } - trad_frame_set_reg_addr (this_cache, tdep->ppc_fpscr_regnum, - fpregs + 32 * tdep->wordsize); trad_frame_set_id (this_cache, frame_id_build (base, func)); } --=-tsReUJzaVnXMYaAwk+tQ--