From patchwork Tue Jan 10 08:22:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Liebler X-Patchwork-Id: 90647 Delivered-To: patch@linaro.org Received: by 10.140.20.99 with SMTP id 90csp501811qgi; Tue, 10 Jan 2017 00:23:13 -0800 (PST) X-Received: by 10.84.131.165 with SMTP id d34mr3210056pld.41.1484036593931; Tue, 10 Jan 2017 00:23:13 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id b82si1331526pfe.235.2017.01.10.00.23.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 00:23:13 -0800 (PST) Received-SPF: pass (google.com: domain of libc-alpha-return-76643-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org; spf=pass (google.com: domain of libc-alpha-return-76643-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=libc-alpha-return-76643-patch=linaro.org@sourceware.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:cc:date :mime-version:in-reply-to:content-type:message-id; q=dns; s= default; b=oEHfumUk4U3wdG5NpY4CgVwStdmMNu/0CcrhjDz9sEhNO6ETFzLaX O51fgA1kU66EWOqNxk5M4GAfZa8w6l2Qk+phCGiXT8gP0kpNvSbPA8FEdqnd3Xkj N+9jTs1+JvsTpc4iMaY/toZTkm/3IemdbzTwqAN3Nfrh+YWdsMUNuc= 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:subject:to:references:from:cc:date :mime-version:in-reply-to:content-type:message-id; s=default; bh=ByY0QWxlBcGTIR0OZNIMlBAwV9o=; b=jkgujehC7BWdKx3dM7ay3t2TbOqJ PW/adoASd8NunCprtR8EAAWD73vwHFAIpli6gmdgO35gV+IlML0RDXiza1UPJ4s2 NMF26sJ6MaBvur9tMteO66v6k0ZMG7EqltkRG/G8nOsNa4GALvAst4q7vcaj0KtS Y1RlFdF+akBgou4= Received: (qmail 119853 invoked by alias); 10 Jan 2017 08:23:04 -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 119841 invoked by uid 89); 10 Jan 2017 08:23:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=explicit_bzero, 73, 6 X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: [PATCH COMMITTED] Do not require memset elimination in explicit_bzero test To: libc-alpha@sourceware.org References: <20161220100941.B4FA5401BD5F6@oldenburg.str.redhat.com> <5c0d3ac6-b4d9-21b9-19b6-ae9173102a9c@redhat.com> From: Stefan Liebler Cc: Siddhesh Poyarekar Date: Tue, 10 Jan 2017 09:22:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <5c0d3ac6-b4d9-21b9-19b6-ae9173102a9c@redhat.com> X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17011008-0032-0000-0000-000007043202 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17011008-0033-0000-0000-000023038DE5 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-10_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701100116 On 12/30/2016 01:16 PM, Florian Weimer wrote: > On 12/21/2016 07:04 PM, Florian Weimer wrote: >> On 12/20/2016 11:09 AM, Florian Weimer wrote: >>> Some targets fail to apply dead store elimination to the >>> memset call in setup_ordinary_clear. Before this commit, >>> this causes the test case to fail. Instead, the test case >>> now logs lack of memset elimination as an informational >>> message. >>> >>> 2016-12-20 Florian Weimer >>> >>> Do not require memset elimination in explicit_bzero test. >>> * string/tst-xbzero-opt.c (prepare_test_buffer): Force inlining. >>> (enum test_expectation): Add NO_EXPECTATIONS. >>> (subtests): NO_EXPECTATIONS for ordinary clear. >>> (check_test_buffer): Handle NO_EXPECTATIONS. >>> * string/Makefile (CFLAGS-tst-xbzero-opt.c): Compile with -O3. >> >> Stefan, this test still fails for me on s390x: >> >> PASS: no clear/prepare: expected 32 got 32 >> PASS: no clear/test: expected some got 32 >> PASS: ordinary clear/prepare: expected 32 got 32 >> INFO: ordinary clear/test: found 0 patterns (memset not eliminated) >> PASS: explicit clear/prepare: expected 32 got 32 >> FAIL: explicit clear/test: expected 0 got 1 >> >> Do you have an idea what's going on there? > > I filed bug 21006 and will add it as a release blocker. > > Thanks, > Florian > Hi Florian, the test is also failing on my system and I've had a look into it. In setup_explicit_clear, the buffer is filled with the test_pattern. On s390x the memcpy in prepare_test_buffer is done by loading r4 / r5 with the test_pattern and using store multiple instruction to store r4 / r5 to buf. If explicit_bzero is resolved in setup_explicit_clear, r4 / r5 is stored to stack by _dl_runtime_resolve and the call to memmem in count_test_patterns finds a hit of the test_pattern on the stack. The attached patch resolves all symbols at program startup by linking with -z now. This omits the call of _dl_runtime_resolve within setup_explicit_clear and the test passes. If this is okay, I'll commit this patch and clear this bug in the release blockers list in the release-wiki. Bye Stefan ChangeLog: [BZ #21006] * string/Makefile (LDFLAGS-tst-xbzero-opt): New variable. commit a07f447fd235d1898a56af7317a4ff6a11a603b9 Author: Stefan Liebler Date: Tue Jan 10 08:47:13 2017 +0100 S390: Fix FAIL in test string/tst-xbzero-opt [BZ #21006] On s390x this test failed with: FAIL: explicit clear/test: expected 0 got 1 In setup_explicit_clear, the buffer is filled with the test_pattern. On s390x the memcpy in prepare_test_buffer is done by loading r4 / r5 with the test_pattern and using store multiple instruction to store r4 / r5 to buf. If explicit_bzero is resolved in setup_explicit_clear, r4 / r5 is stored to stack by _dl_runtime_resolve and the call to memmem in count_test_patterns finds a hit of the test_pattern on the stack. This patch resolves all symbols at program startup by linking with -z now. This omits the call of _dl_runtime_resolve within setup_explicit_clear and the test passes. ChangeLog: [BZ #21006] * string/Makefile (LDFLAGS-tst-xbzero-opt): New variable. diff --git a/string/Makefile b/string/Makefile index 04e9da9..87e0d1d 100644 --- a/string/Makefile +++ b/string/Makefile @@ -73,6 +73,14 @@ CFLAGS-stratcliff.c = -fno-builtin CFLAGS-test-ffs.c = -fno-builtin CFLAGS-tst-inlcall.c = -fno-builtin CFLAGS-tst-xbzero-opt.c = -O3 +# BZ 21006: Resolve all functions but at least explicit_bzero at startup. +# Otherwise the test fails on s390x as the memcpy in prepare_test_buffer is +# done by loading r4 / r5 with the test_pattern and using store multiple +# instruction to store r4 / r5 to buf. If explicit_bzero would be resolved in +# setup_explicit_clear, r4 / r5 would be stored to stack by _dl_runtime_resolve +# and the call to memmem in count_test_patterns will find a hit of the +# test_pattern on the stack. +LDFLAGS-tst-xbzero-opt = -z now # Called during TLS initialization. CFLAGS-memcpy.c = $(no-stack-protector)