From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25216 invoked by alias); 19 Nov 2015 17:12:33 -0000 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 Received: (qmail 25206 invoked by uid 89); 19 Nov 2015 17:12:33 -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: aserp1040.oracle.com Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 19 Nov 2015 17:12:32 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAJHCSxt019055 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Nov 2015 17:12:29 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAJHCSNr008295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Nov 2015 17:12:28 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tAJHCSdQ002255; Thu, 19 Nov 2015 17:12:28 GMT Received: from termi.oracle.com (/10.175.241.155) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Nov 2015 09:12:27 -0800 From: jose.marchesi@oracle.com (Jose E. Marchesi) To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] [SPARC] callfuncs.exp: avoid spurious register differences in sparc64 targets. References: <87ziyam0yh.fsf@oracle.com> <564DF643.6000407@redhat.com> Date: Thu, 19 Nov 2015 17:12:00 -0000 In-Reply-To: <564DF643.6000407@redhat.com> (Pedro Alves's message of "Thu, 19 Nov 2015 16:18:11 +0000") Message-ID: <87r3jlx5y5.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 X-SW-Source: 2015-11/txt/msg00407.txt.bz2 > + -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.