This is the mail archive of the
mailing list for the GCC project.
Re: TLS run-time requirements on x86, etc.
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Sat, 10 Jun 2017 18:21:02 -0500
- Subject: Re: TLS run-time requirements on x86, etc.
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <20170112172526.GB21933@tucnak>
On 1/12/2017 11:25 AM, Jakub Jelinek wrote:
On Thu, Jan 12, 2017 at 11:22:58AM -0600, Joel Sherrill wrote:
I am looking at the RTEMS x86 TLS support. When -fPIC is
specified, gcc generates calls to ___tls_get_addr(). But
when it is not specified, there are no external calls.
To make sure we are doing the right thing, I have a
+ What is expected for "get TLS" when __tls_get_addr()
is not called?
+ Can we force all RTEMS i386 gcc configurations to make the
function call to __tls_get_addr()? We have an implementation
of it for ARM so it would be the same. So this would
be a simple solution for us.
Resurrecting this thread. That document covers a small
subset of the targets supported by GCC. We have now
implemented TLS on most of the ones in the document.
But how (and if) it is implemented on the at least
dozen other architectures GCC and RTEMS support is
We would like to have the option of just setting an
option in the GCC backend where it generates calls to
a known name subroutine exactly the same on all targets
that set the option. This would make it much simpler
for us to support across all architectures.
The ARM already has a mode where it generates subroutine
calls to get the TLS.
Is there a way to do this?