Re: [PATCH] ARM: Add support for AT_HWCAP2 in _dl_procinfo

[Will Newton <will dot newton at linaro dot org>]

On 26 June 2014 10:14, Richard Earnshaw <rearnsha@arm.com> wrote:
> On 25/06/14 14:12, Will Newton wrote:
>> Add support for the new HWCAP2 values for ARMv8 added in the
>> 3.15 kernel. Tested using QEMU which supports these extensions.
>>
>> ChangeLog:
>>
>> 2014-06-25  Will Newton  <will.newton@linaro.org>
>>
>>       * sysdeps/unix/sysv/linux/arm/dl-procinfo.c
>>       (_dl_arm_cap_flags): Add HWCAP2 values.
>>       * sysdeps/unix/sysv/linux/arm/dl-procinfo.h
>>       (_DL_HWCAP_COUNT): Increase to 37.
>>       (_DL_HWCAP_LAST): New define.
>>       (_DL_HWCAP2_LAST): New define.
>>       (_dl_procinfo): Add support for printing
>>       AT_HWCAP2 entries.
>>       (_dl_string_hwcap): Use _dl_hwcap_string.
>
> I don't have a specific comment about this patch.
>
> I do have a general comment that I think the HWCAPs exported by the
> kernel for 32-bit ARM are a joke.  The principle problem is that there
> is precisely zero way to determine the base architecture.  You cannot
> even tell whether you are running on ARMv6 or ARMv7, let alone whether
> you have key features such as Thumb2.

I agree, and the situation on AArch64 looks no better. It's pretty
much impossible to determine the micro-architecture from userland too
- which may not be that much of an issue for ARM, but AArch64 likely
much more so

> I've heard it suggested that you can part the architecture string (eg
> armv7l), but 1) the format of this string is not precisely defined in a
> way that allows you to predict what future cores will generate and 2)
> parsing strings in ifunc code when function calls can't be made is
> likely to be hairy at best.

I think the platform is probably the best way to pass that info. The
kernel currently sets it to:

        snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c",
                 list->elf_name, ENDIANNESS);

Where elf_name is one of:

v4
v5
v5t
v6
v7
v7m

That doesn't look too intractable, and we can work with the kernel
guys to make sure nothing too surprising is added there. The string
parsing of architecture revision is pretty trivial in those cases.
Perhaps this is something we can discuss at the GNU Tools Cauldron
next month.

On AArch64 the platform string is hardcoded to "aarch64" or "aarch64_be". :-/

-- 
Will Newton
Toolchain Working Group, Linaro