Comment 61 for bug 1921664

(In reply to serge_sans_paille from comment #24)
> This may sound a bit naive, but... if the couroutine are implemented in
> terms of setjmp/longjmp, then the c11 standard says that
>
> ```
> 7.13.2.1 [The longjmp function]
>
> 1 #include <setjmp.h>
> _Noreturn void longjmp(jmp_buf env, int val);
> Description
>
> 2 The longjmp function restores the environment saved by the most recent
> invocation of
> the setjmp macro in the same invocation of the program with the
> corresponding
> jmp_buf argument. If there has been no such invocation, or **if the
> invocation was from
> another thread of execution**, or if the function containing the
> invocation of the setjmp
> macro has terminated execution248) in the interim, or if the invocation
> of the setjmp
> macro was within the scope of an identifier with variably modified type
> and execution has
> left that scope in the interim, the behavior is undefined.
>
> ```
>
> Then isn't that prone to failure?

Yes, according to the spec the behavior is undefined. QEMU has other coroutine implementations too, e.g. assembly or using other OS/runtime APIs.

I don't think setjmp is the culprit here since QEMU could switch to the assembly implementation and it would still have the TLS problem.

> Wouldn't setting the thread local
> variables as volatile change something?
>
> This small godbolt experiment is promising:
>
> https://gcc.godbolt.org/z/6nznnMvTs

I don't think that approach is workable because:
1. It's very tricky to get it right. The relatively innocuous addition I made here is broken: https://gcc.godbolt.org/z/8GP4dTP56. The likelihood of errors like this slipping past code review is high.
2. All __thread variables in QEMU need to be converted to volatile pointers, including auditing and rewriting code that uses the variables.