From patchwork Wed Jul 13 10:21:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Liebler X-Patchwork-Id: 647831 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3rqFHd5v3jz9srZ for ; Wed, 13 Jul 2016 20:21:49 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b=ltsDEX1A; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:date:message-id:mime-version :content-type:cc; q=dns; s=default; b=ckvu4j2aZc/6XLO7eXJDMMYgZx q3QLezcrzRoCKalGov944wlHHe+z4QgtK8GZGRhgW4wtfl7Ru9yP02IyQfi0DOVZ /D2Fj4BDfXRmUKO7oRamnKnRjOQ5bpomIsEGvLnpJnIlwu1E9Qx/86UBfi+aDUkO NWlRs+4f50edLdaig= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:date:message-id:mime-version :content-type:cc; s=default; bh=YqIGVP79qS+KDdnD+QiJlYXoNj4=; b= ltsDEX1ArCouHoYc7Xp3CJudlH6UV+3NlaQgAcDGHzzx/lITNIPkS5zKn5P1DJwc 7c8E5qNFaZvMA4iCkaxSLSuCYFHfap2FYNMIb/SMXjkZ4gRmFIN6MOZ6xw4yGS90 2EreXdGboF6EMMJfHCbpyppCJfWsEV3fLONgT0SRoPs= Received: (qmail 116477 invoked by alias); 13 Jul 2016 10:21:41 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 116452 invoked by uid 89); 13 Jul 2016 10:21:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy=triggering, ltr, chi X-HELO: plane.gmane.org To: libc-alpha@sourceware.org From: Stefan Liebler Subject: [PATCH] S390: Do not clobber r13 with memcpy on 31bit with copies >1MB. Date: Wed, 13 Jul 2016 12:21:30 +0200 Lines: 114 Message-ID: <5786162A.7080605@linux.vnet.ibm.com> Mime-Version: 1.0 Cc: Adhemerval Zanella X-Mozilla-News-Host: news://news.gmane.org:119 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 Hi, If the default memcpy variant is called with a length of >1MB on 31bit, r13 is clobbered as the algorithm is switching to mvcle. The mvcle code returns without restoring r13. All other cases are restoring r13. If memcpy is called from outside libc the ifunc resolver will only select this variant if running on machines older than z10. Otherwise or if memcpy is called from inside libc, this default memcpy variant is called. The testcase timezone/tst-tzset is triggering this issue in some combinations of gcc versions and optimization levels. This bug was introduced in commit 04bb21ac93e90d7696bcaf8febe2b2dd2d83585a and thus is a regression compared to glibc 2.23 release. It should be committed before glibc 2.24 release. This patch removes the usage of r13 at all. Thus it is not saved and restored. The base address for execute-instruction is now stored in r5 which is obtained after r5 is not needed anymore as 256byte block counter. Okay to commit before release 2.24? Bye Stefan ChangeLog: * sysdeps/s390/s390-32/memcpy.S (memcpy): Eliminate the usage of r13 as it is not restored in mvcle case. commit a671883eb41bc3179e7a435e6c2857a913757bf1 Author: Stefan Liebler Date: Wed Jul 13 10:46:10 2016 +0200 S390: Do not clobber r13 with memcpy on 31bit with copies >1MB. If the default memcpy variant is called with a length of >1MB on 31bit, r13 is clobbered as the algorithm is switching to mvcle. The mvcle code returns without restoring r13. All other cases are restoring r13. If memcpy is called from outside libc the ifunc resolver will only select this variant if running on machines older than z10. Otherwise or if memcpy is called from inside libc, this default memcpy variant is called. The testcase timezone/tst-tzset is triggering this issue in some combinations of gcc versions and optimization levels. This bug was introduced in commit 04bb21ac93e90d7696bcaf8febe2b2dd2d83585a and thus is a regression compared to glibc 2.23 release. It should be committed before glibc 2.24 release. This patch removes the usage of r13 at all. Thus it is not saved and restored. The base address for execute-instruction is now stored in r5 which is obtained after r5 is not needed anymore as 256byte block counter. ChangeLog: * sysdeps/s390/s390-32/memcpy.S (memcpy): Eliminate the usage of r13 as it is not restored in mvcle case. diff --git a/sysdeps/s390/s390-32/memcpy.S b/sysdeps/s390/s390-32/memcpy.S index 6be5104..1a8bdbf 100644 --- a/sysdeps/s390/s390-32/memcpy.S +++ b/sysdeps/s390/s390-32/memcpy.S @@ -42,20 +42,18 @@ ENTRY(memcpy) .machine "g5" lr %r1,%r2 # r1: Use as dest ; r2: Return dest .L_G5_start: - st %r13,52(%r15) - .cfi_offset 13, -44 - basr %r13,0 -.L_G5_16: ltr %r4,%r4 - je .L_G5_4 + je .L_G5_99 ahi %r4,-1 lr %r5,%r4 srl %r5,8 ltr %r5,%r5 jne .L_G5_13 - ex %r4,.L_G5_17-.L_G5_16(%r13) .L_G5_4: - l %r13,52(%r15) + basr %r5,0 +.L_G5_16: + ex %r4,.L_G5_17-.L_G5_16(%r5) +.L_G5_99: br %r14 .L_G5_13: chi %r5,4096 # Switch to mvcle for copies >1MB @@ -65,7 +63,6 @@ ENTRY(memcpy) la %r1,256(%r1) la %r3,256(%r3) brct %r5,.L_G5_12 - ex %r4,.L_G5_17-.L_G5_16(%r13) j .L_G5_4 .L_G5_17: mvc 0(1,%r1),0(%r3)