[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

["ouster at cs dot stanford.edu" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80258

John Ousterhout <ouster at cs dot stanford.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ouster at cs dot stanford.edu

--- Comment #10 from John Ousterhout <ouster at cs dot stanford.edu> ---
I accidentally posted this on issue 26461, so I'm reposting here; sorry for the
duplicate...

Kernel threads are great, and it may seem like there's no need for user-level
threads now that kernel threads are universally available. But layering
user-level threads on top of kernel threads can offer a speedup of at least 10x
for common operations. The fact that so many different people have responded on
this issue and issue 26461 is pretty good evidence that it can be useful to do
"context switching" on top of kernel threads. My research group has recently
run up against this same problem. Thread-local variables (i.e.
kernel-thread-locals) are still useful in this environment (for example, we use
one to keep track of the user thread that's loaded on the current kernel
thread).

One of the great things about gcc is that it has supported a huge variety of
applications and design styles; it would be a shame for gcc to preclude this
particular class of applications.

Is it unreasonably difficult to add a mechanism to force gcc to flush cached
thread-local addresses? Those of us using the mechanism would be happy to pay a
small performance penalty for it, but presumably that won't affect applications
that don't use the mechanism.

Please reconsider?