This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Carlos Eduardo Seo <cseo at linux dot vnet dot ibm dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>, Richard Henderson <rth at redhat dot com>
- Date: Fri, 3 Jul 2015 10:55:42 +0200
- Subject: Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- Authentication-results: sourceware.org; auth=none
- References: <55760314 dot 6070601 at linux dot vnet dot ibm dot com> <559617FF dot 8010100 at redhat dot com>
On Fri, Jul 03, 2015 at 01:05:03AM -0400, Carlos O'Donell wrote:
> On 06/08/2015 05:03 PM, Carlos Eduardo Seo wrote:
> > The proposed patch adds a new feature for powerpc. In order to get
> > faster access to the HWCAP/HWCAP2 bits, we now store them in the TCB.
> > This enables users to write versioned code based on the HWCAP bits
> > without going through the overhead of reading them from the auxiliary
> > vector.
> >
> > A new API is published in ppc.h for get/set the bits in the
> > aforementioned memory area (mainly for gcc to use to create
> > builtins).
> >
> > Testcases for the API functions were also created.
> >
> > Tested on ppc32, ppc64 and ppc64le.
> >
> > Okay to commit?
>
> (1) Prevent running new applications against old glibc.
>
> You add a new interface to glibc, but provide no way to prevent
> new applications that compile with this support from crashing
> or behaving badly when run on systems with an older glibc.
>
> Richard Henderson had suggested to me that you could use a dummy
> versioned symbol in the code to create a dependency against
> GLIBC_2.22 and thus prevent those new binaries from running
> on say GLIBC_2.21. You'd never use the versioned symbol for anything.
>
> This would seem a much better way to prevent what will obviously
> be a weird failure mode.
>
> Have you considered this failure mode?
>
> At the end of the day it's up to IBM to make the best use of the
> tp+offset data stored in the TCB, but every byte you save is another
> byte you can use later for something else.
>
Carlos a problem with this patch is that they ignored community
feedback. Early in this thread Florian come with better idea to use
GOT+offset that could be accessed as
&hwcap_hack
and avoids per-thread runtime overhead.
Also I now have additional comment with api as if you want faster checks
wouldn't be faster to save each bit of hwcap into byte field so you
could avoid using mask at each check?