This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Expanding the hwcap
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: libc-alpha at sourceware dot org, rsa at us dot ibm dot com, rth at twiddle dot net, StevenMunroe <sjmunroe at us dot ibm dot com>
- Date: Wed, 17 Oct 2012 18:10:46 +1100
- Subject: Re: [RFC] Expanding the hwcap
- References: <1350425312.25040.6342.camel@localhost.localdomain> <201210170227.56319.vapier@gentoo.org>
On Wed, 2012-10-17 at 02:27 -0400, Mike Frysinger wrote:
> On Tuesday 16 October 2012 18:08:32 Ryan Arnold wrote:
> > In GLIBC we could copy these bits up to the high 32-bits of the existing
> > 64-bit hwcap (uint64) and continue to access the existing hwcap via the
> > GLRO macros. This would of course eliminate parity between the kernel
> > hwcap definitions and those in GLIBC (exported via hwcap.h).
>
> maybe i'm naive, but couldn't you have the kernel declare
> cpu_spec.cpu_user_features as 64bit and then take care of splitting up
> ELF_HWCAP into AT_HWCAP and AT_HWCAP2 automatically ? you could have the
> binfmt loader do something like:
> NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
> if (sizeof(*elf_info) < sizeof(ELF_HWCAP))
> NEW_AUX_ENT(AT_HWCAP2, (ELF_HWCAP) >> (sizeof(*elf_info) * 8));
>
> then the ldso knows that if it sees AT_HWCAP2, it has to manually merge it
> into the higher bits.
The kernel side doesn't matter, it's my internal cuisine. The important
bit is the ABI to glibc, which is the same in both cases :-)
Cheers,
Ben.