[PATCH 11/11] powerpc64le: Add glibc-hwcaps support

[Florian Weimer]

* Adhemerval Zanella:

>> +uint32_t
>> +_dl_hwcaps_subdirs_active (void)
>> +{
>> +  int active = 0;
>> +
>> +  /* Test in reverse preference order.  Altivec and VSX are implied by
>> +     the powerpc64le ABI definition.  */
>> +
>> +  /* POWER9.  GCC enables float128 hardware support for -mcpu=power9.  */
>> +  if ((GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_00) == 0
>> +      || (GLRO (dl_hwcap2) & PPC_FEATURE2_HAS_IEEE128) == 0)
>> +    return _dl_hwcaps_subdirs_build_bitmask (subdirs_count, active);
>> +  ++active;
>
> Should we test PPC_FEATURE2_DARN as well? I think cryptographic and related
> libraries might use it as source of entropy.

It does not show up in the compiler preprocessor macros.  There also
have been cases where randomness-generating instructions have been
disabled in firmware (but probably not on POWER).  I think it's safer
not to include cryptographic stuff.

>> +
>> +  /* POWER10. GCC defines __MMA__ for -mcpu=power10.  */
>
> Double space after period.

Thanks, fixed.

>> +/* Return the POWER level, 8 for the baseline.  */
>> +static int
>> +compute_level (void)
>> +{
>> +  const char *platform = (const char *) getauxval (AT_PLATFORM);
>> +  if (strcmp (platform, "power8") == 0)
>> +    return 8;
>> +  if (strcmp (platform, "power9") == 0)
>> +    return 9;
>> +  if (strcmp (platform, "power10") == 0)
>> +    return 10;
>
> Why not use HWCAP? Is it to decouple from the loader code that uses it?
> I am asking because by using hwcap we can check if this tests is working
> on different chips by using qemu-ppc64le with -mcpu.

And that doesn't affect AT_PLATFORM?  That would be a QEMU bug.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill