This is the mail archive of the
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: Alan Modra <amodra at gmail dot com>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 6 Jul 2015 21:58:56 -0400
- Subject: Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- Authentication-results: sourceware.org; auth=none
- References: <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> <20150706155219 dot GV1173 at brightrain dot aerifal dot cx> <1436217981 dot 8449 dot 8 dot camel at oc7878010663> <20150706215657 dot GZ1173 at brightrain dot aerifal dot cx> <1436221527 dot 8449 dot 15 dot camel at oc7878010663>
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
> 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.