From patchwork Fri Jan 19 13:20:00 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Arnez X-Patchwork-Id: 25454 Received: (qmail 67787 invoked by alias); 19 Jan 2018 13:20:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 67583 invoked by uid 89); 19 Jan 2018 13:20:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Jan 2018 13:20:10 +0000 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0JDJwgJ147445 for ; Fri, 19 Jan 2018 08:20:08 -0500 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fkh29h4m7-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 19 Jan 2018 08:20:08 -0500 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 19 Jan 2018 13:20:06 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 19 Jan 2018 13:20:03 -0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w0JDK3w240960172; Fri, 19 Jan 2018 13:20:03 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 69BB242047; Fri, 19 Jan 2018 13:13:26 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4463D4203F; Fri, 19 Jan 2018 13:13:26 +0000 (GMT) Received: from oc1027705133.ibm.com (unknown [9.152.212.155]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Fri, 19 Jan 2018 13:13:26 +0000 (GMT) From: Andreas Arnez To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [pushed] S390: Use soft float in s390-tdbregs test case References: <371c4fd2-c97a-ec0c-c344-709826c145cb@redhat.com> Date: Fri, 19 Jan 2018 14:20:00 +0100 In-Reply-To: <371c4fd2-c97a-ec0c-c344-709826c145cb@redhat.com> (Pedro Alves's message of "Thu, 18 Jan 2018 20:09:04 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 18011913-0020-0000-0000-000003EC84F7 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18011913-0021-0000-0000-0000427EC76F Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801190174 X-IsSubscribed: yes On Thu, Jan 18 2018, Pedro Alves wrote: > On 01/18/2018 06:46 PM, Andreas Arnez wrote: >> The GDB test case s390-tdbregs.exp verifies GDB's handling of the >> "transaction diagnostic block". For simplicity, the test case uses the >> "transaction begin" (TBEGIN) instruction with the "allow floating-point >> operation" flag set to zero. But some GCC versions may indeed emit >> floating point or vector instructions for this test case. If this happens >> in the transaction, it aborts, and an endless loop results. >> >> This change tells the compiler to produce a soft-float binary, so no >> floating-point or vector registers are touched. > > I found the rationale above quite instructive. How about > putting it in the exp file directly? > >> >> -if { [prepare_for_testing "failed to prepare" $testfile $srcfile] } { >> +# Use soft float, so the compiler doesn't use floating-point or vector >> +# instructions. >> +if { [prepare_for_testing "failed to prepare" $testfile $srcfile \ >> + [list "debug" "additional_flags=-msoft-float"]] } { >> return -1 > > I mean, the comment here alone as is doesn't explain why we'd rather > the compiler not use float-point/vector insns, which I think is a > question people reading the testcase will tend to ask themselves, > and the answer isn't obvious. At least to me. Yeah, I guess it isn't. In general, the test case was a bit under-documented. Thus, while at it, I'm adding some more information as well. So I pushed the patch below. Thanks for the suggestion! --- Andreas -- >8 -- Subject: [PATCH] S390: Improve comments for s390-tdbregs test case This adds more explanation as to why the test case must be compiled with the -msoft-float option. It also documents the my_tbegin and my_tend functions. gdb/testsuite/ChangeLog: * gdb.arch/s390-tdbregs.c (my_tbegin): Add comment documenting the function. (my_tend): Likewise. * gdb.arch/s390-tdbregs.exp: Enhance comment; explain the rationale of avoiding FP- and vector instructions. --- gdb/testsuite/ChangeLog | 8 ++++++++ gdb/testsuite/gdb.arch/s390-tdbregs.c | 9 +++++++++ gdb/testsuite/gdb.arch/s390-tdbregs.exp | 6 ++++-- 3 files changed, 21 insertions(+), 2 deletions(-) diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index f3d31e7..d510b79 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,3 +1,11 @@ +2018-01-19 Andreas Arnez + + * gdb.arch/s390-tdbregs.c (my_tbegin): Add comment documenting the + function. + (my_tend): Likewise. + * gdb.arch/s390-tdbregs.exp: Enhance comment; explain the + rationale of avoiding FP- and vector instructions. + 2018-01-19 Ruslan Kabatsayev * gdb.arch/powerpc-d128-regs.exp: Replace expected "\[\t\]*" from diff --git a/gdb/testsuite/gdb.arch/s390-tdbregs.c b/gdb/testsuite/gdb.arch/s390-tdbregs.c index 2c768bb..57365ae 100644 --- a/gdb/testsuite/gdb.arch/s390-tdbregs.c +++ b/gdb/testsuite/gdb.arch/s390-tdbregs.c @@ -17,6 +17,13 @@ #include +/* Start a transaction. To avoid the need for FPR save/restore, assume + that no FP- or vector registers are modified within the transaction. + Thus invoke TBEGIN with the "allow floating-point operation" flag set + to zero, which forces a transaction abort when hitting an FP- or vector + instruction. Also assume that TBEGIN will eventually succeed, so just + retry indefinitely. */ + static void my_tbegin () { @@ -28,6 +35,8 @@ my_tbegin () : "cc", "memory" ); } +/* End a transaction. */ + static void my_tend () { diff --git a/gdb/testsuite/gdb.arch/s390-tdbregs.exp b/gdb/testsuite/gdb.arch/s390-tdbregs.exp index 47d9d38..e454feb 100644 --- a/gdb/testsuite/gdb.arch/s390-tdbregs.exp +++ b/gdb/testsuite/gdb.arch/s390-tdbregs.exp @@ -26,8 +26,10 @@ if { ![istarget s390-*-*] && ![istarget s390x-*-* ] } { standard_testfile .c -# Use soft float, so the compiler doesn't use floating-point or vector -# instructions. +# The test case assumes that no FP- or vector instructions occur within +# the transaction. Thus tell the compiler to use soft float, so it +# doesn't emit them. Some GCC versions may otherwise do so, and an +# endless loop would result. if { [prepare_for_testing "failed to prepare" $testfile $srcfile \ [list "debug" "additional_flags=-msoft-float"]] } { return -1