This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: How are we doing with our blockers for 2.18?
- From: Ryan S Arnold <rsa at linux dot vnet dot ibm dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Ryan Arnold <rsa at us dot ibm dot com>
- Date: Mon, 17 Jun 2013 17:25:46 -0500
- Subject: Re: How are we doing with our blockers for 2.18?
- References: <51BB768B dot 8010204 at redhat dot com> <CAAKybw_nEWwod5-aP7UvmXQc4A-Pe_nKhyBOkuFydQLzbOx=zg at mail dot gmail dot com> <51BF53EB dot 1010004 at redhat dot com> <1371496726 dot 1716 dot 51 dot camel at localhost dot localdomain> <51BF82C6 dot 8080601 at twiddle dot net>
On Mon, 2013-06-17 at 14:42 -0700, Richard Henderson wrote:
> On 06/17/2013 12:18 PM, Ryan S Arnold wrote:
> > I need to figure out what to do with the platform bits which may be
> > saved in the high bits of the hwcap since these will now collide with
> > the AT_HWCAP2 usage in PowerPC (since they marked the bits from high to
> > low).
>
> Wouldn't it be simpler to add GLRO(dl_hwcap2)? That avoids having to analyze
> the other targets at all, really. The only uses of dl_hwcap2 will be under
> sysdeps/powerpc/ then.
I'm actually fine with this approach now that the complexity of using
the remainder of dl_hwcap is discovered. My initial hesitation is that
I didn't care to add another field to the rtld structure but now this
appears to be the least of my worries. This also solves some of
Roland's questions regarding 64-bit AT_HWCAP entries.
I can put together a patch which does this in pretty short order.
Ryan