This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Support x86-64 TLS code sequences without PLT
- From: Carlos O'Donell <carlos at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, binutils at sourceware dot org
- Cc: gcc-patches at gcc dot gnu dot org, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 6 Jun 2016 11:01:10 -0400
- Subject: Re: [PATCH] Support x86-64 TLS code sequences without PLT
- Authentication-results: sourceware.org; auth=none
- References: <20160603212154 dot GA23988 at intel dot com>
On 06/03/2016 05:21 PM, H.J. Lu wrote:
> We can generate x86-64 TLS code sequences for general and local dynamic
> models without PLT, which uses indirect call via GOT:
> call *__tls_get_addr@GOTPCREL(%rip)
> instead of direct call:
> call __tls_get_addr[@PLT]
What are the actual pros and cons of this change?
Does this improve security? Performance?
The __tls_get_addr symbol, on x86_64, lives in ld.so, which generally
means that all shared objects (GD usage) indirect through their PLT/GOT
to make the call. In this model, and because of lazy linking, the
PLT-related GOT entries are left read-write to be updated after resolution
(ignore the BIND_NOW + RELRO case since in that case we do all of this
After your change, without a PLT entry, these symbols can no longer be
interposed? The static linker would generate a binding (a got reloc for
the symbol which is resolved by the dynamic loader) that cannot be changed,
becomes RO after RELRO?
Is the security benefit worth the loss of interposition for this symbol?
Is there any performance gains?