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: Rich Felker <dalias at libc dot org>
- To: munroesj at linux dot vnet dot ibm dot com
- Cc: Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 6 Jul 2015 11:52:19 -0400
- 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> <20150609163835 dot GI17573 at brightrain dot aerifal dot cx> <1435777940 dot 7125 dot 132 dot camel at oc7878010663> <5596C284 dot 9070108 at redhat dot com> <1436145404 dot 10792 dot 46 dot camel at oc7878010663> <20150706021300 dot GU1173 at brightrain dot aerifal dot cx> <1436189206 dot 9162 dot 21 dot camel at oc7878010663>
On Mon, Jul 06, 2015 at 08:26:46AM -0500, Steven Munroe wrote:
> On Sun, 2015-07-05 at 22:13 -0400, Rich Felker wrote:
> > On Sun, Jul 05, 2015 at 08:16:44PM -0500, Steven Munroe wrote:
> > > > I've suggested to Carlos that this is a problem with the use of the
> > > > TCB. If one uses the TCB, one should add a dummy symbol that is versioned
> > > > and tracks when you added the feature, and thus you can depend upon it,
> > > > but not call it, and that way you get the right versioning. The same
> > > > problem happened with stack canaries and it's still painfully annoying
> > > > at the distribution level.
> > >
> > > This is completely unnecessary. The load associated with
> > > __builtin_cpu_supports() will work with any GLIBC what support TLS and
> > > the worst that will happen is it will load zeros.
> >
> > That's bad enough -- there are applications of hwcap where you NEED
> > the correct value, not some (possibly empty) subset of the bits. For
> > example if you need to know which registers to save/restore in an aync
> > context-switching setup (rolling your own makecontext/swapcontext) or
> > if you're implementing a function which has a special calling
> > convention with a contract not to clobber any but a small fixed set of
> > registers, but it might callback to arbitrary code in a rare case (ala
> > __tls_get_addr or tls descriptor functions).
> >
> No! any application that uses HWCAP and or __builtin_cpu_supports, has
> to program for when the feature is not available. The feature bit is
> either true or false.
I don't think you understood what I was saying. False negatives for
__builtin_cpu_supports are not safe because they may wrongly indicate
absence of a register you need to save on behalf of unknown
third-party code. I already gave two examples of situations where this
can arise.
> The dword we are talking about is already allocated and has been since
> the initial implementation of TLS. For the PowerPC ABIs we allocated a
> full 4K for the TCB and use negative displacement calculations that work
> well with our ISA.
I don't see this in glibc. struct pthread seems to be immediately
below tcbhead_t, and the latter is not 4k. I'm looking at:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/nptl/tls.h;h=1f3d97a99593afbd3c56318eaa6d7a2d03a59005;hb=HEAD
Rich