Re: swapcontext happening on different threads

[Florian Weimer <fweimer@redhat.com>]

* Andrew Pinski:

> Reference https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65712 .
>
> I am not 100% sure if this is a valid thing to do.
> But take the code in the referenced GCC bug report. Currently since
> pthread_self is marked as const, if you swap to a different context
> and then have that context be swapped on a different thread, you
> might/will get the old value of pthread_self in some cases.
>
> Is this well defined or is this a corner case that was not expected. I
> don't see anywhere in the older versions of POSIX that explain what
> would happen if you do that. And glibc's documentation does not talk
> about this case either.
>
> It would be useful if the documentation talked about this either way.

There have been passed discussions about this on the gcc list, for other
stackful coroutine implementations.  QEMU in particular needs a way to
implement a barrier for thread-local variable optimizations.  This is
not just about const functions like pthread_self or __errno_location, it
impacts GCC code generation for TLS variable access as well.

  Disabling TLS address caching to help QEMU on GNU/Linux
  <https://inbox.sourceware.org/gcc/87im15qbp3.fsf@oldenburg.str.redhat.com/>

I'm sure the QEMU developers would still appreciate explict TLS address
barriers in GCC.  As part of this, maybe we can get a replacement
function attribute to replace const for those functions.

Thanks,
Florian