llvmbot
commented
3 months ago @llvm/issue-subscribers-coroutines
Author: Nabeel Omer (omern1)
``` c++
// Compile with clang -O3 -S -fpic ./tls.cpp
thread_local void* tls_foo;
extern void do_stuff(void*);
int test() {
do_stuff(tls_foo);
do_stuff(tls_foo);
return 0;
}
```
Output:
```
_Z4testv: # @_Z4testv
.cfi_startproc
# %bb.0: # %entry
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset %rbx, -16
data16
leaq tls_foo@TLSGD(%rip), %rdi
data16
data16
rex64
callq __tls_get_addr@PLT
movq %rax, %rbx
movq (%rax), %rdi
callq _Z8do_stuffPv@PLT
movq (%rbx), %rdi
callq _Z8do_stuffPv@PLT
xorl %eax, %eax
popq %rbx
.cfi_def_cfa_offset 8
retq
```
In our (Sony's) private repro `test` is executing on a fiber created by an M:N fiber library (stack-full coroutines) and `do_stuff` causes the fiber to be suspended.
When `test` resumes execution it's likely that it won't be running on the same OS thread as it was before it was suspended.
This means that the TLS address loaded won't be valid on the new thread and will cause a crash.
[MSVC has the `/GT` commandline option](https://learn.microsoft.com/en-us/cpp/build/reference/gt-support-fiber-safe-thread-local-storage) which makes it reload the TLS address before each load of a TLS variable and I think we probably need something similar in LLVM.
omern1
jyknight
Fulgen301
ChuanqiXu9
Output:
In our (Sony's) private repro
testis executing on a fiber created by an M:N fiber library (stack-full coroutines) anddo_stuffcauses the fiber to be suspended. Whentestresumes execution it's likely that it won't be running on the same OS thread as it was before it was suspended. This means that the TLS address loaded won't be valid on the new thread and will cause a crash.MSVC has the
/GTcommandline option which makes it reload the TLS address before each load of a TLS variable and I think we probably need something similar in LLVM.