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: Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>
- To: Alan Modra <amodra at gmail dot com>
- Cc: munroesj at linux dot vnet dot ibm dot com, Rich Felker <dalias at libc dot org>, "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 06 Jul 2015 22:01:23 -0500
- 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> <20150707023611 dot GB4321 at bubble dot grove dot modra dot org>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Tue, 2015-07-07 at 12:06 +0930, Alan Modra wrote:
> 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.
Sorry Rich, Thanks Alan
I really did remember 0x7000 is physical offset and I fixated at on
The final allocation rounds to quadword and the R13 is set to TCB
+0x7000. The offset is logical but no real.
And I am literally exhausted by all this. Which did not help.
We can add the symbol reference to detect old GLIBC and but I believe
that existing GLIBC versioning would catch this anyway.