This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc clears AT_HWCAP and set only HW_CAP_X86_64 (0x2)


Yes, the values read from /proc/self/auxv is different (Linux x86_64,
glibc-2.27, tried glibc HEAD without any difference) with
getauxval(AT_HWCAP).

Here is the program I wrote for testing:

https://gist.github.com/wangbj/658da547437fe9b7eff2113cc9fc9741

And here is the output (check AT_HWCAP):

$ ./features

         AT_BASE: getauxval = 0x7f861434a000    , proc_getauxval =
0x7f861434a000

        AT_ENTRY: getauxval = 0x4005c0          , proc_getauxval =
0x4005c0

        AT_HWCAP: getauxval = 0x2               , proc_getauxval =
0xbfebfbff

Best Regards,
baojun

On Thu, Oct 17, 2019 at 4:26 PM Carlos O'Donell <carlos@redhat.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?
>
> --
> Cheers,
> Carlos.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]