From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 493D13840C28 for ; Thu, 10 Dec 2020 10:22:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 493D13840C28 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0BAA1qsp071682 for ; Thu, 10 Dec 2020 05:22:26 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 35bhbegxac-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 10 Dec 2020 05:22:26 -0500 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0BAAFxuH169393 for ; Thu, 10 Dec 2020 05:22:25 -0500 Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 35bhbegx9k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Dec 2020 05:22:25 -0500 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0BAAMJY1004190; Thu, 10 Dec 2020 10:22:23 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma04fra.de.ibm.com with ESMTP id 3581u82wch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Dec 2020 10:22:23 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0BAAMLFJ34210152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Dec 2020 10:22:21 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 18042A405C; Thu, 10 Dec 2020 10:22:21 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DDB34A405B; Thu, 10 Dec 2020 10:22:20 +0000 (GMT) Received: from oc4452167425.ibm.com (unknown [9.171.57.181]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 10 Dec 2020 10:22:20 +0000 (GMT) Subject: Re: [PATCH 12/11] s390x: Add Add glibc-hwcaps support To: Florian Weimer Cc: libc-alpha@sourceware.org References: <87a6v4lzir.fsf@oldenburg2.str.redhat.com> <87k0tum3op.fsf@oldenburg2.str.redhat.com> <87sg8e4xsm.fsf@oldenburg2.str.redhat.com> From: Stefan Liebler Message-ID: <16ea2bf3-6516-a214-4474-a5f317c543d6@linux.ibm.com> Date: Thu, 10 Dec 2020 11:22:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <87sg8e4xsm.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-10_03:2020-12-09, 2020-12-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 phishscore=0 suspectscore=0 lowpriorityscore=0 clxscore=1015 mlxlogscore=999 spamscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012100063 X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 10:22:34 -0000 On 12/9/20 7:52 PM, Florian Weimer wrote: > * Stefan Liebler: > >> I've had a look to your patches. Can you please adjust some lines. Then >> this patch is okay for s390x: >> - The commit subject-line contains "Add Add" > > Oops, fixed. > >> - If e.g. a machine newer-than-z15 does not have HWCAP_S390_SORT, then >> it would fall back to z14: >> >> diff --git a/sysdeps/s390/s390-64/dl-hwcaps-subdirs.c >> b/sysdeps/s390/s390-64/dl-hwcaps-subdirs.c >> index fa8d2ce1f1..3673808a45 100644 >> --- a/sysdeps/s390/s390-64/dl-hwcaps-subdirs.c >> +++ b/sysdeps/s390/s390-64/dl-hwcaps-subdirs.c >> @@ -41,11 +41,12 @@ _dl_hwcaps_subdirs_active (void) >> return _dl_hwcaps_subdirs_build_bitmask (subdirs_count, active); >> ++active; >> >> - /* z15. */ >> + /* z15. >> + Note: We do not list HWCAP_S390_SORT and HWCAP_S390_DFLT here as, >> + according to the Principles of Operation, those may be replaced or >> removed >> + in future. */ >> if (!((GLRO (dl_hwcap) & HWCAP_S390_VXRS_EXT2) >> - && (GLRO (dl_hwcap) & HWCAP_S390_VXRS_PDE) >> - && (GLRO (dl_hwcap) & HWCAP_S390_SORT) >> - && (GLRO (dl_hwcap) & HWCAP_S390_DFLT))) >> + && (GLRO (dl_hwcap) & HWCAP_S390_VXRS_PDE))) >> return _dl_hwcaps_subdirs_build_bitmask (subdirs_count, active); >> ++active; > > Does -march=z15 imply SORT and DFLT? That bit wasn't clear to me. > If it does not, we should net test for it. No, the corresponding instructions are not emitted by gcc -march=z15. E.g. dfltcc is manually added to zlib. There is a runtime check if this facility is available. > >> - I've asked the kernel-guys regarding AT_PLATFORM: The list is >> complete, but it never contains archXYZ. This is only available for >> binutils/gcc -march=archXYZ. > > Okay, I went with the current kernel sources and did not check the > history there. > >> - If running e.g. on z196 or older, tst-glibc-hwcaps will always fail, >> as level would be <= 9 which leads to fails: >> TEST_COMPARE (marker2 (), MIN (level - 9, 2)); >> Therefore compute_level should always return the baseline for older >> platforms. > > Oh, good point. > >> - If we are running on z13 or newer and the kernel was booted with novx, >> then AT_PLATFORM is z13 or newer, but _dl_hwcaps_subdirs_active will >> return zero and the _dl_hwcaps_subdirs are not searched as HWCAP_S390_VX >> and all the other VX.. flags are not set. This leads to a test fail. > > That's quite bad because it breaks the existing AT_PLATFORM subdirectory > for z13 and newer. (I expect the reason to have such a directory is to > put vectorized code there.) Given that this is an unsupported > configuration for glibc, maybe the test failure is acceptable. On the > other hand, if we deprecate the old mechanism (separate discussion), > this becomes a supported configuration, so adapting the test makes > sense. I assume novx is usually used only for testing purposes. If e.g. RHEL 8 is booted with novx, it would fail on the first vector instruction as the ALS includes those. Currently I know, that the dfp-subdirectory was used for libdfp in the past. Now the distros require a minimum architecture level which always has support for dfp and the base libdfp library is built with hardware dfp instructions. There are also different flavors for libatlas. As far as I know, those are located in the corresponding vector-hwcap subdirectories instead of z13/z14/z15. Do you have an outlook when you plan to deprecate/remove the old mechanism? > >> I've also recognized that if build with gcc 6.5.0, I'll get test-fails: >> elf/tst-glibc-hwcaps-cache >> elf/tst-glibc-hwcaps-prepend-cache >> elf/tst-ldconfig-X >> elf/tst-ldconfig-bad-aux-cache >> elf/tst-ldconfig-ld_so_conf-update >> elf/tst-stringtable >> >> It seems as it always fails with "String table is too large". >> I've debugged elf/tst-stringtable into elf/stringtable:185: >> else if (__builtin_add_overflow (previous->offset, >> previous->length + 1, >> ¤t->offset)) >> error (EXIT_FAILURE, 0, _("String table is too large")); >> >> It seems as gcc 6.5.0 __builtin_add_overflow is buggy: > > Sorry, I do not recall a discussion of this particular bug. I do not > see changes s390.md that would correspond to this (but then I'm not GCC > developer …). > > I haven't seen such a failure on other architectures. I assume, there won't be a further gcc 6 version in future which could fix it. As ldconfig would fail with "String table is too large" if build with gcc 6.5, would you recommend to use gcc 7.1 as minumum on s390/s390x? Currently gcc 6.2 and newer is required in /configure.ac. > >> While viewing your previous patches, I've found the following "if" in >> commit "elf: Add glibc-hwcaps subdirectory support to ld.so cache >> processing": >> elf/dl-hwcaps.c: >> static void >> +sort_priorities_by_name (void) >> +{ >> ... >> + int cmp = memcmp (current->name, previous->name, to_compare); >> + if (cmp >= 0 >> + || (cmp == 0 && current->name_length >= previous->name_length)) >> + break; >> Is this condition intended? The second part "cmp == 0" will never be >> evaluated as in this case, the first part "cmp >= 0" is already true. > > Thanks, I've pushed a fix for that. > > I'll post an update of the s390x patch soon. > > Florian > Thanks, Stefan