Lower TLS operations to emulation functions.
Copyright (C) 2006-2025 Free Software Foundation, Inc.
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 3, or (at your option) any
later version.
GCC is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3. If not see
<http://www.gnu.org/licenses/>.
Whenever a target does not support thread-local storage (TLS) natively,
we can emulate it with some run-time support in libgcc. This will in
turn rely on "keyed storage" a-la pthread_key_create; essentially all
thread libraries provide such functionality.
In order to coordinate with the libgcc runtime, each TLS variable is
described by a "control variable". This control variable records the
required size, alignment, and initial value of the TLS variable for
instantiation at runtime. It also stores an integer token to be used
by the runtime to find the address of the variable within each thread.
On the compiler side, this means that we need to replace all instances
of "tls_var" in the code with "*__emutls_get_addr(&control_var)". We
also need to eliminate "tls_var" from the symbol table and introduce
"control_var".
We used to perform all of the transformations during conversion to rtl,
and the variable substitutions magically within assemble_variable.
However, this late fiddling of the symbol table conflicts with LTO and
whole-program compilation. Therefore we must now make all the changes
to the symbol table early in the GIMPLE optimization path, before we
write things out to LTO intermediate files.
Value for TLS varpool node where a pointer to control variable and
access variable are stored.
1.13.2