Re: powerpc __tls_get_addr call optimization

[Alan Modra <amodra at gmail dot com>]

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.
> > https://sourceware.org/ml/libc-alpha/2009-03/msg00053.html
> 
> 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.

> Do you have a reference to the binutils patch?

https://sourceware.org/ml/binutils/2009-03/msg00498.html

> > This patch is glibc support for a PowerPC TLS optimization, inspired
> > by Alexandre Oliva's TLS optimization for other processors,
> > http://www.lsd.ic.unicamp.br/~oliva/writeups/TLS/RFC-TLSDESC-x86.txt
> > 
> > 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
> > DT_PPC64_OPT/DT_PPC_OPT.
> 
> 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..

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

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

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.

-- 
Alan Modra
Australia Development Lab, IBM