This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Expanding the hwcap
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- Cc: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, "Ryan S. Arnold" <rsa at us dot ibm dot com>, Mike Frysinger <vapier at gentoo dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 13 Nov 2012 16:30:25 -0800 (PST)
- Subject: Re: [RFC] Expanding the hwcap
- References: <1350425312.25040.6342.camel@localhost.localdomain><201210170227.56319.vapier@gentoo.org><1350457846.4678.83.camel@pasglop><201210171639.16727.vapier@gentoo.org><1350535372.25040.8657.camel@localhost.localdomain><1350551656.2476.1.camel@pasglop><CAAKybw-cTEk34sOBxZPUtTNxhdv3PSQEW7KXEYy0Z+a=qHqR-Q@mail.gmail.com>
> 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.
The ABI is that auxv elements can be in any order. Even if the kernel
happens always to put AT_HWCAP first, we should not assume so in userland.
> 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;
If the same a_type were to appear twice that would be an ABI violation and
so it really doesn't matter much how we treat it. Might as well simply
make it |= in both case AT_HWCAP and case AT_HWCAP2.
Thanks,
Roland