https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Julian Waters <tanksherman27 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tanksherman27 at gmail dot com
--- Comment #19 from Julian Waters <tanksherman27 at gmail dot com> ---
Jakub, the Windows .tls support to my knowledge only has 1 model. The following
code:
_Thread_local int local = 1;
int get(void) {
return local;
}
is equivalent to the following (handwritten) assembly:
.section .tls$, "dw"
.p2align 2, 0x0
local:
.long 1
.text
.globl get
get:
movl _tls_index(%rip), %eax
movq %gs:88, %rcx
movq (%rcx, %rax, 8), %rax
movl local@SECREL32(%rax), %eax
ret
Where rax and rcx can be substituted for any 64 bit scratch register, and
.p2align 2 and .long should be replaced with the appropriate values/directives
depending on the size of the TLS variable (For instance, changing to an 8 byte
long long means .p2align 3 and .quad should be used instead). I am willing to
step up to implement this, but am new to the gcc codebase and am having trouble
finding out how to plug it into the compiler so it can emit the assembly
required for TLS support. You mentioned briefly about how to implement it,
could you run me through the steps required to get the compiler to emit the
assembly above?
Once this is implemented in the compiler, 2 bugs in binutils need to be fixed.
The first is that the assembly fails horribly on the Intel syntax, as gas
cannot recognize @SECREL32 as a directive and instead thinks the entire
local@SECREL32 is a symbol name in Intel mode. The other is that ld linked
executable crashes with a mysterious SIGSEGV on movl local@SECREL32(%rax),
%eax. Nothing is wrong with the assembly, as assembling it with gas and then
linking with clang results in a working exe, instead this is a bug in ld that I
have yet to decipher
Alexandre, how's your progress on Windows TLS going? Could we collaborate to
get this into gcc somehow?
