Re: [PATCH 12/11] s390x: Add Add glibc-hwcaps support

[Stefan Liebler <stli@linux.ibm.com>]

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,
>>                                  &current->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 <glibc>/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