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

[Rich Felker <dalias at libc dot org>]

On Mon, Jul 06, 2015 at 05:25:27PM -0500, Steven Munroe wrote:
> On Mon, 2015-07-06 at 17:56 -0400, Rich Felker wrote:
> > On Mon, Jul 06, 2015 at 04:26:21PM -0500, Steven Munroe wrote:
> > > > > 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.
> > 
> > The layout as I understand it is not compatible with what you
> > described; there is certainly no way it can allow growth in both
> > directions, since one direction grows into the local-exec TLS, which
> > begins at or just above TP-0x7000.
> > 
> > Here is the layout of TLS, from lowest address to highest address:
> > 
> > 1. struct pthread  \ These lines 2 and 3 together make up
> > 2. tcbhead_t       / the TLS_PRE_TCB_SIZE in tls.h.
> > 3. Nominal TCB, 0 bytes (TLS_TCB_SIZE in tls.h)
> > 4. Local-exec TLS
> > 
> > TP-0x7000 points to the end of 2, or the beginning/end of 3, or the
> > beginning of 4 (take your pick since they're all the same).
> > 
> > Fields of tcbhead_t can be accessed as ABI since they have a fixed
> > offset from TP-0x7000, as long as you only add new fields to the
> > beginning; doing so "pushes struct pthread down", which is harmless.
> > However, if you access a newly-added field from code assuming it
> > exists, but you're running with an old glibc version where it did no
> > exist, you will actually end up accessing the end of struct pthread.
> > 
> No, look again at how the macros are defined. 
> 
> As the size tcbhead_t changes the end of the struct tcbhead_t does not
> move and as such the previous TCB fields and the struct pthread do not
> move.
> 
> Alan, tag your it, please explain this to Rick, after your first cup.
> 
> its been a long day...

I'll wait for Alan to respond since I feel like our conversation is
getting nowhere and the concerns I'm trying to address (which I
believe were raised originally by Carlos, not me) are not getting
across to you clearly. Regardless of whose fault that is, maybe having
a third party look at this can help resolve it.

Rich