This is the mail archive of the
mailing list for the glibc project.
Re: glibc clears AT_HWCAP and set only HW_CAP_X86_64 (0x2)
- From: Baojun Wang <wangbj at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: libc-help at sourceware dot org, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Thu, 17 Oct 2019 16:31:46 -0400
- Subject: Re: glibc clears AT_HWCAP and set only HW_CAP_X86_64 (0x2)
- References: <CAC+a-TaCHxHjeNVc+vPY3qz7d4tnu48x=nNeRRGYqaUeQZ1UZg@mail.gmail.com> <firstname.lastname@example.org>
Yes, the values read from /proc/self/auxv is different (Linux x86_64,
glibc-2.27, tried glibc HEAD without any difference) with
Here is the program I wrote for testing:
And here is the output (check AT_HWCAP):
AT_BASE: getauxval = 0x7f861434a000 , proc_getauxval =
AT_ENTRY: getauxval = 0x4005c0 , proc_getauxval =
AT_HWCAP: getauxval = 0x2 , proc_getauxval =
On Thu, Oct 17, 2019 at 4:26 PM Carlos O'Donell <email@example.com> wrote:
> On 10/17/19 11:29 AM, Baojun Wang wrote:
> > Hi libc,
> > when calling getauxval(AT_HWCAP), it returns 0x2, because of below snippet:
> > https://code.woboq.org/userspace/glibc/sysdeps/x86/cpu-features.c.html#510
> > Is there any reason why glibc don't use the values passed from kernel auxv?
> I don't know of any good reason.
> The semantics of getauxval() is to provide the auxiliary vector data.
> In this case glibc *does* read AT_HWCAP, but then for x86 it overrides it
> with a computed value based on cpuid.
> HJ, Is there any reason we do this?
> Baojun, Do you see a difference between getauxval() return and real AT_HWCAP?