This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] ARM: Add support for AT_HWCAP2 in _dl_procinfo
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 26 Jun 2014 10:14:03 +0100
- Subject: Re: [PATCH] ARM: Add support for AT_HWCAP2 in _dl_procinfo
- Authentication-results: sourceware.org; auth=none
- References: <1403701970-21947-1-git-send-email-will dot newton at linaro dot org>
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.
> 2014-06-25 Will Newton <email@example.com>
> * 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'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.
We really need a better solution than this.