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

[Adhemerval Zanella]

On 02/12/2020 10:51, Florian Weimer wrote:
> * 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.

GCC does provides it through a compiler builtin, only enabled for
power9 and newer.  And I think hardware entropy instruction are not
used on cryptographic, but also on different fields as simulations.

> 
>>> +
>>> +  /* 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.

At least not with v5.2.0-rc0-99-g3493c36f03, not sure if is has been 
fixed/change upstream.