Re: RFC: Add ___tls_get_addr

[Rich Felker <dalias at libc dot org>]

On Wed, Jul 05, 2017 at 08:38:50AM -0700, H.J. Lu wrote:
> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
> GCCs older than GCC 4.9.4:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
> 
> continue to work even if vector instructions are used by functions called
> from __tls_get_addr, which assumes 16-byte stack alignment as specified
> by x86-64 psABI.
> 
> We are considering to add an alternative interface, ___tls_get_addr, to
> glibc, which doesn't realign stack.  Compilers, which properly align stack
> for TLS, call generate call to ___tls_get_addr, instead of __tls_get_addr,
> if ___tls_get_addr is available.
> 
> Any comments?

I think it's unnecessary. The fast path of __tls_get_addr is trivial
to write in asm, where alignment doesn't matter, and then the cost of
alignment only enters in the slow path anyway. Implementations like
glibc and musl that need to be compatible with old binaries can easily
do this, and ones which know they'll only be running binaries built
without the gcc bug don't need to care.

(FWIW, it can probably be done without asm too, just using an
intermediate function with the right attribute to force realignment,
if you have an attribute to suppress use of vector instructions in the
top-level fast-path __tls_get_addr C.)

Note that if you make the change and have gcc generate calls to the
new ___tls_get_addr symbol, it's going to be problematic for people
trying to link to older glibc versions that don't have it.

Rich