This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/7] Add <sys/auxv.h> and gethwcap function.
- From: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 15 Nov 2012 11:06:25 -0600
- Subject: Re: [PATCH 1/7] Add <sys/auxv.h> and gethwcap function.
- References: <1337013660-30676-1-git-send-email-rth@twiddle.net><1337013660-30676-2-git-send-email-rth@twiddle.net><CAAKybw9+eAify=NGvzVZ7Hy8BXNkZ9xsdLZwQsKx5dV1hT74sg@mail.gmail.com><4FB1560C.6040603@twiddle.net><CAAKybw-P1k66StYBqa95_wcnWfQTD3862DBKLo0E270NAWsuPQ@mail.gmail.com>
Alright, so I admit.. foot in mouth moment right now.
In light of my recent proposal to expand the hwcap into the high
32-bits of _dl_hwcap for 32-bit and 64-bit platforms I think this
interface should be reconsidered for inclusion.
Richard, you were right all along.
Ryan
On Mon, May 14, 2012 at 2:55 PM, Ryan S. Arnold <ryan.arnold@gmail.com> wrote:
> On Mon, May 14, 2012 at 1:59 PM, Richard Henderson <rth@twiddle.net> wrote:
>> On 05/14/12 11:49, Ryan S. Arnold wrote:
>>> Isn't this redundant with the following?
>>>
>>> __getauxval (AT_HWCAP)
>>>
>>> I imagine, even for a user application, this probably isn't going to
>>> be called more than once so is this specific export justified?
>>
>> Nearly but not quite. Please read the 0/7 post re the different
>> return types.
>
> Ahh, I see.. I was thinking it doesn't matter because as far as I can
> see, the dl_hwcap field of the GLRO is still populated with only the
> low half of the HWCAP field on a 32-bit system (like 32-bit PowerPC):
>
> elf/dl-sysdep.c:
>
> case AT_HWCAP:
> GLRO(dl_hwcap) = (unsigned long int) av->a_un.a_val;
>
> Ryan S. Arnold