Message ID | 87ziyam0yh.fsf@oracle.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 47758 invoked by alias); 19 Nov 2015 15:55:21 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 47741 invoked by uid 89); 19 Nov 2015 15:55:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS, UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 19 Nov 2015 15:55:20 +0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAJFtHQk019315 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <gdb-patches@sourceware.org>; Thu, 19 Nov 2015 15:55:18 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAJFtGfs022683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <gdb-patches@sourceware.org>; Thu, 19 Nov 2015 15:55:17 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tAJFtGVx017687 for <gdb-patches@sourceware.org>; Thu, 19 Nov 2015 15:55:16 GMT Received: from termi.oracle.com (/10.175.241.155) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Nov 2015 07:55:16 -0800 From: jose.marchesi@oracle.com (Jose E. Marchesi) To: gdb-patches@sourceware.org Subject: [PATCH] [SPARC] callfuncs.exp: avoid spurious register differences in sparc64 targets. Date: Thu, 19 Nov 2015 17:02:46 +0100 Message-ID: <87ziyam0yh.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes |
Commit Message
Jose E. Marchesi
Nov. 19, 2015, 4:02 p.m. UTC
Hi all! Ok to commit? commit 50fa72dabc43ba7fabbd5d213013d78cd22e2342 Author: Jose E. Marchesi <jose.marchesi@oracle.com> Date: Thu Nov 19 10:55:06 2015 -0500 callfuncs.exp: avoid spurious register differences in sparc64 targets. The Linux kernel disables the FPU upon returning to userland. This introduces spurious failures in the register preservation tests in callfuncs.exp, since the pstate.PEF bit gets cleared after system calls. This patch filters out the pstate register in sparc64-*-linux-gnu targets, so the relevant tests are no longer fooled and pass. gdb/testsuite/ChangeLog: 2015-11-19 Jose E. Marchesi <jose.marchesi@oracle.com> * gdb.base/callfuncs.exp (fetch_all_registers): Filter out the pstate register when comparing registers values in sparc64-*-linux-gnu targets to avoid spurious differences.
Comments
On 11/19/2015 04:02 PM, Jose E. Marchesi wrote: > > Hi all! Ok to commit? > > commit 50fa72dabc43ba7fabbd5d213013d78cd22e2342 > Author: Jose E. Marchesi <jose.marchesi@oracle.com> > Date: Thu Nov 19 10:55:06 2015 -0500 > > callfuncs.exp: avoid spurious register differences in sparc64 targets. > > The Linux kernel disables the FPU upon returning to userland. This > introduces spurious failures in the register preservation tests in > callfuncs.exp, since the pstate.PEF bit gets cleared after system calls. > + -re "^pstate\[ \t\]+\[^\r\n\]+\r\n" { > + if [istarget "sparc64-*-linux-gnu"] { > + # Filter out the pstate register, since in sparc64 > + # targets the Linux kernel disables pstate.PEF when > + # returning from traps, giving spurious differences. Isn't this a kernel bug? It sounds like it's impossible to debug FPU code if you e.g. step over FPU instructions? > + } else { > + lappend all_registers_lines $expect_out(0,string) > + } > + exp_continue > + } Thanks, Pedro Alves
> + -re "^pstate\[ \t\]+\[^\r\n\]+\r\n" { > + if [istarget "sparc64-*-linux-gnu"] { > + # Filter out the pstate register, since in sparc64 > + # targets the Linux kernel disables pstate.PEF when > + # returning from traps, giving spurious differences. Isn't this a kernel bug? It sounds like it's impossible to debug FPU code if you e.g. step over FPU instructions? No, it is not a kernel bug. It is a consequence of how the sparc kernel port handles the restoring of FP registers clobbered by kernel code. As far as I understand it: When an user program uses the FPU in any way (any instruction referencing FP registers for example) a fp_disabled trap is triggered and the kernel enables the FPU so the user program can happily continue executing FPU instructions. If at some point the user program traps into the kernel (syscall, or whatever) with the FPU activated the kernel saves whatever FP registers it may clobber in the corresponding thread struct. Then it disables the FPU and returns to the user program. Then, if the user program uses the FPU again, another fp_disabled trap is triggered, and the kernel will both re-activate the FPU and restore all the "dirty" FP registers that were clobbered in the previous trap.
On 11/19/2015 05:19 PM, Jose E. Marchesi wrote: > > > + -re "^pstate\[ \t\]+\[^\r\n\]+\r\n" { > > + if [istarget "sparc64-*-linux-gnu"] { > > + # Filter out the pstate register, since in sparc64 > > + # targets the Linux kernel disables pstate.PEF when > > + # returning from traps, giving spurious differences. > > Isn't this a kernel bug? It sounds like it's impossible to debug FPU > code if you e.g. step over FPU instructions? > > No, it is not a kernel bug. It is a consequence of how the sparc > kernel port handles the restoring of FP registers clobbered by kernel > code. As far as I understand it: > > When an user program uses the FPU in any way (any instruction > referencing FP registers for example) a fp_disabled trap is triggered > and the kernel enables the FPU so the user program can happily continue > executing FPU instructions. > > If at some point the user program traps into the kernel (syscall, or > whatever) with the FPU activated the kernel saves whatever FP registers > it may clobber in the corresponding thread struct. Then it disables the > FPU and returns to the user program. > > Then, if the user program uses the FPU again, another fp_disabled trap > is triggered, and the kernel will both re-activate the FPU and restore > all the "dirty" FP registers that were clobbered in the previous trap. Thanks for the explanation. So until the program re-activates the FPU, when the user displays the FP registers, gdb actually shows the fpu registers as saved in the thread struct, right? Not the values clobbered by the kernel? I'd guess so, otherwise people would have noticed the breakage sooner, and assuming the kernel does use FPU instructions itself, then you'd get other spurious register differences with callfuncs.exp too. Patch is OK assuming that. Still sounds to me that it'd be better if ptrace traps left the FPU activated if it was activate on entry, on principle of minimizing program perturbation with a ptrace observer though ... Thanks, Pedro Alves
> > + -re "^pstate\[ \t\]+\[^\r\n\]+\r\n" { > > + if [istarget "sparc64-*-linux-gnu"] { > > + # Filter out the pstate register, since in sparc64 > > + # targets the Linux kernel disables pstate.PEF when > > + # returning from traps, giving spurious differences. > > Isn't this a kernel bug? It sounds like it's impossible to debug FPU > code if you e.g. step over FPU instructions? > > No, it is not a kernel bug. It is a consequence of how the sparc > kernel port handles the restoring of FP registers clobbered by kernel > code. As far as I understand it: > > When an user program uses the FPU in any way (any instruction > referencing FP registers for example) a fp_disabled trap is triggered > and the kernel enables the FPU so the user program can happily continue > executing FPU instructions. > > If at some point the user program traps into the kernel (syscall, or > whatever) with the FPU activated the kernel saves whatever FP registers > it may clobber in the corresponding thread struct. Then it disables the > FPU and returns to the user program. > > Then, if the user program uses the FPU again, another fp_disabled trap > is triggered, and the kernel will both re-activate the FPU and restore > all the "dirty" FP registers that were clobbered in the previous trap. Thanks for the explanation. So until the program re-activates the FPU, when the user displays the FP registers, gdb actually shows the fpu registers as saved in the thread struct, right? Not the values clobbered by the kernel? I'd guess so, otherwise people would have noticed the breakage sooner, and assuming the kernel does use FPU instructions itself, then you'd get other spurious register differences with callfuncs.exp too. Right. PTRACE_GETREGS[64] always fetches the floating-point registers saved in the thread struct save area (if a thread is ptracing itself it saves the registers in the save area first). At the point GDB ptraces the target process everything is saved. Patch is OK assuming that. Pushed. Thanks.
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index 14c4b41..e712bc5 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,3 +1,9 @@ +2015-11-19 Jose E. Marchesi <jose.marchesi@oracle.com> + + * gdb.base/callfuncs.exp (fetch_all_registers): Filter out the + pstate register when comparing registers values in + sparc64-*-linux-gnu targets to avoid spurious differences. + 2015-11-17 Dominik Vogt <vogt@linux.vnet.ibm.com> * lib/dwarf.exp (_note): Fix left shift of negative value. diff --git a/gdb/testsuite/gdb.base/callfuncs.exp b/gdb/testsuite/gdb.base/callfuncs.exp index fda3cb7..28e2fe1 100644 --- a/gdb/testsuite/gdb.base/callfuncs.exp +++ b/gdb/testsuite/gdb.base/callfuncs.exp @@ -254,6 +254,16 @@ proc fetch_all_registers {test} { } exp_continue } + -re "^pstate\[ \t\]+\[^\r\n\]+\r\n" { + if [istarget "sparc64-*-linux-gnu"] { + # Filter out the pstate register, since in sparc64 + # targets the Linux kernel disables pstate.PEF when + # returning from traps, giving spurious differences. + } else { + lappend all_registers_lines $expect_out(0,string) + } + exp_continue + } -re "^last_break\[ \t\]+\[^\r\n\]+\r\n" { if [istarget "s390*-*-*"] { # Filter out last_break which is read-only,