This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
that.

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]