Re: [RFC] Expanding the hwcap

["Ryan S. Arnold" <ryan dot arnold at gmail dot com>]

I've been working on the code as suggested by Ben and Mike.

Unfortunately different architectures define the HWCAP size (in the
auxv) differently.

Some systems define it as unsigned long int, and others as unsigned int.

For systems where it's defined as unsigned long int and userspace is
64-bits then HWCAP2 isn't needed.  The kernel can simply populate the
HWCAP with the feature bit masks defined in the high 32-bits (x86-64,
s390).

For systems where HWCAP is defined as unsigned long int and userspace
is 32-bits then HWCAP2 can be used to have higher 32-bit feature masks
(i386).

For systems where HWCAP is unsigned int in both 32-bit and 64-bit
userspace then HWCAP2 can be used to have higher 32-bit feature masks
(powerpc32, powerpc64, arm).

When the rtld_global_ro.hwcap is populated (elf/dl-sysdeps.c) the auxv
is walked. Due to struct element ordering (and the fact that we won't
change it) we always know that AT_HWCAP will precede any instances of
AT_HWCAP2 so the AT_HWCAP assignment can be left as-is.

I've tested a prototype for AT_HWCAP2 with powerpc32 and powerpc64
that preserves the low 32-bits.
        case AT_HWCAP2:
           GLRO(dl_hwcap) = (0x00000000ffffffff & GLRO(dl_hwcap)) |
(((uint64_t) av->a_un.a_val) << 32);
          break;

I'll get the full patch out tomorrow if my logic seems sound.

Ryan

On Thu, Oct 18, 2012 at 4:14 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2012-10-17 at 23:42 -0500, Ryan Arnold wrote:
>> On Wed, 2012-10-17 at 16:39 -0400, Mike Frysinger wrote:
>> > sure.  my point was that we can keep a single hwcap in glibc itself and keep
>> > the hwcap.h macros the same.  the kernel will maintain a single 64bit value
>> > internally, take care of splitting it into two (AT_HWCAP & AT_HWCAP2), and
>> > glibc will take care of merging it back into one thus it only needs one hwcap
>> > value accessible via GLRO.
>>
>> I'm not sure I understand the situation entirely from the kernel
>> perspective, but I believe that the cpu_spec.cpu_user_features can't
>> exceed 32-bits on PowerPC32 and to maintain parity with PowerPC64 we
>> only use the low 32-bits there as well, hence the need for two fields in
>> the kernel as well.
>
> I don't see any reason why we can't make it a u64 and split it on the
> way to userspace as Mike suggested.
>
> Cheers,
> Ben.
>
>