This is the mail archive of the 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: powerpc __tls_get_addr call optimization

On 03/18/2015 10:56 PM, Alan Modra wrote:
> On Wed, Mar 18, 2015 at 01:07:32PM -0400, Carlos O'Donell wrote:
>> On 03/18/2015 02:11 AM, Alan Modra wrote:
>>> Now that Alex's fixes for static TLS have gone in, I figure it's worth
>>> revisiting an old patch of mine.
>> I'm not against this patch, but it certainly seems like you would be
>> better served by just implementing tls descriptors?
> I think this is one better than tls descriptors, because powerpc
> avoids the indirect function call used by tls descriptors.

You mean to say it is "faster" than tls descriptors, but at the same
time "harder" to maintain because it's a custom implementation that
anyone debugging glibc has to learn about. That's not a bad thing,
I just want us all to acknowledge the tradeoff.

The present goal for glibc and the toolchain in general has been
to move to TLS descriptors, and thus provide a way for the dozen or
so packages in the distribution to stop doing this:

mesa (src/mapi/u_current.h):

extern __thread struct mapi_table *u_current_table

They would instead use TLS descriptors, and the above markings would
be removed and the access would be as fast as possible without needing
to specify the IE model.

These packages are sometimes linked with applications, and sometimes
arbitrarily dlopened.

Would this present optimization you propose for power support this
use case?

Would it use static TLS for the above access if it could and fall
back gracefully if it can't?

What I want to make sure is that Power isn't left behind when we
eventually transition everyone else to TLS Descriptors and remove
the above markings from source programs.

>> Do you have a reference to the binutils patch?

Excellent, that makes it much easier to review the glibc pieces since
I can see what the static linker is going to do and review the stub

>>> In essence, this optimization uses a zero module id in the TLS
>>> descriptor to indicate that a TLS variable is allocated space in the
>>> static TLS area.  A special plt call linker stub for __tls_get_addr
>>> checks for such a TLS descriptor and if found, returns the offset
>>> immediately.  The linker communicates the fact that the special
>>> __tls_get_addr stub is present by setting a bit in the dynamic tag
>> I'm confused, you write "TLS descriptor" but power doesn't have TLS DESC
>> support yet in glibc?
> Oops, I meant a tls_index object as defined in Drepper's tls.pdf.
> The binutils reference above makes the same error..

No problem. Thanks for clarifying. This is part of the problem with
having an alternate implementation.

>> The code in question writes a module id of zero into the GOT entry
>> associated with the TLS variable, not really the TLS descriptor?
> Right.


>> Speaking of which, you wouldn't happen to have a Latex contribution
>> that describes the Power TLS support so I can add it to and update
>> tls.pdf? :-)
> No, sorry, I wrote the original powerpc tls abi as plain text.

Could you mail that to me privately please? I'd like a copy for my
own reference.

>> This absolutely needs a new ppc64-specific test case to make sure this is
>> actually working as intended? If it requires a new binutils, then you'll need
>> to have the test return 77 (UNSUPPORTED) if the present binutils is not new
>> enough.
> We actually get the support turned on automatically, no gcc or ld
> options needed, so the existing tls tests run using the optimized
> __tls_get_addr support.

OK, as long as there are binutils test that make sure the stub is in
place and being used, and static tls is allocated for the entries,
then I'm fine.

> Hmm, your comment reminded me that I need to check older binutils,
> because I renamed DT_PPC64_TLSOPT to DT_PPC64_OPT and changed the tag
> to a bitfield.  On looking at that, it seems you'll need binutils-2.24
> to build executables and shared libraries that work with the patch as
> is (well, they'll work but glibc won't provide the (0,offset)
> tls_index objects).  glibc itself doesn't need the newer binutils to
> build, but you're right, I should mention this in NEWS and there
> should be a test that the new support is working for those that don't
> read NEWS.



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