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: Alan Modra <amodra at gmail dot com>
- To: munroesj at linux dot vnet dot ibm dot com
- Cc: Rich Felker <dalias at libc dot org>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 7 Jul 2015 12:06:11 +0930
- 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:
> > 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.
Correct. If you look into the fine details, the size allocated for
tcbhead_t is rounded up, so there might be some padding between struct
pthread and tcbhead_t.
> 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.
I think Rich is 100% correct in the part of his email that I quote
above, modulo omitting the detail on padding.
> > 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.
And this concern is true too. A newly minted program with accesses to
hwcap in tcbhead_t, ie. reads from a uint64_t at tp-0x7068, if run
with an older glibc will instead access struct pthread. You'll
probably get a wrong hwcap value. ;) Fixable by ensuring any newly
built executable using hwcap in tcb has a reference to a versioned
symbol only available with newer glibc. All quite standard with new
glibc features.. So, no real problem here.
--
Alan Modra
Australia Development Lab, IBM