This is the mail archive of the
mailing list for the glibc project.
Re: Define TLS version of libc_hidden_tls_proto
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 18 Nov 2013 13:31:04 -0500
- Subject: Re: Define TLS version of libc_hidden_tls_proto
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1311071845320 dot 20971 at digraph dot polyomino dot org dot uk>
On 11/07/2013 01:46 PM, Joseph S. Myers wrote:
> I'm testing a fix for bug 15483 (powerpc-nofpu floating-point state
> wrongly global instead of thread-local). The existing variables for
> floating-point state use libc_hidden_proto / libc_hidden_data_def, so
> uses inside libc get the hidden version while uses from libm get the
> exported version.
> Moving to new thread-local variables, exported at GLIBC_PRIVATE for
> use from libm, the issue arises that the *_hidden_* macros don't
> support thread-local variables; they redeclare a variable with the
> same type, using typeof, but the absence of __thread on the
> redeclaration produces an error.
> This patch adds a new variant hidden_tls_proto and
> libc_hidden_tls_proto - and, to keep all the <lib>_hidden_* sets of
> definitions consistent, such macros for other libraries as well,
> although only the libc one is used. Tested x86_64.
> (No new version of libc_hidden_data_def is needed.)
> 2013-11-07 Joseph Myers <email@example.com>
> * include/libc-symbols.h (__hidden_proto): Add argument "thread".
> (hidden_proto): Caller changed.
> (hidden_tls_proto): New macro.
> (libc_hidden_tls_proto): Likewise.
> (rtld_hidden_tls_proto): Likewise.
> (libm_hidden_tls_proto): Likewise.
> (libresolv_hidden_tls_proto): Likewise.
> (librt_hidden_tls_proto): Likewise.
> (libdl_hidden_tls_proto): Likewise.
> (libnss_files_hidden_tls_proto): Likewise.
> (libnsl_hidden_tls_proto): Likewise.
> (libnss_nisplus_hidden_tls_proto): Likewise.
> (libutil_hidden_tls_proto): Likewise.
I agree with Ondrej, this looks fine to me.
We need something to handle this use case.