Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB

[Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>]

On Mon, 2015-07-06 at 11:52 -0400, Rich Felker wrote:
> 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
> 

The key is the following statement from tls.h:

/* The following assumes that TP (R2 or R13) points to the end of the
   TCB + 0x7000 (per the ABI).  This implies that TCB address is
   TP - 0x7000.  As we define TLS_DTV_AT_TP we can
   assume that the pthread struct is allocated immediately ahead of the
   TCB.  This implies that the pthread_descr address is
   TP - (TLS_PRE_TCB_SIZE + 0x7000).  */

So struct pthread is allocated immediately ahead of the TCB and grows
down (to lower addresses) and the TCB alway ends on the byte before R13
- 0x7000 and grow up (to higher addresses). This is why we always add
new fields to the front of the TCB struct.

This allow the TCB and struct pthread to grow redundantly from either
side of R13-0x7000 and allows the TCB field offsets to remain stable
across releases of the ABI and versions of GLIBC.

The various macros in tls.h handle the details.