[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-11-23
                 CC|                            |redi at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Ben Longbons from comment #5)
> I just hit this in my testsuite, and it's worse than described for the
> dynamic case:
> 
> if libpthread.so is dlopen'ed after libstdc++, __gthread_active_p() will
> *not* become true - weak symbols are not rebound.

The problem isn't that weak symbols are not rebound (they are), it's that
__gthread_active_p stores the result of the first check in a static variable
which is initialized once and then it's value doesn't change:

  static void *const __gthread_active_ptr
    = __extension__ (void *) &GTHR_ACTIVE_PROXY;

> Note that plugins that indirectly pull in pthreads are very common in the
> wild.

At the time of writing, the main executable needs to link to libpthread, not
just the plugins. Otherwise libstdc++ won't work.

Glibc also has a history of bugs with libpthread only being loaded via dlopen.

> Further, LD_PRELOAD=libpthread.so.0 does NOT help.
> 
> Thus, all C++ locks will do nothing despite the presence of multiple
> threads. Correct code will experience race conditions.
> 
> Do note that, nowadays, all of the *other* symbols you're making weak are in
> libc.so (for GLIBC at least, which AFAIK is the only dlopen'able pthread
> implementation)

I don't think that's true at all. It's planned for a future version of glibc
though, see https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html

When that happens, __gthread_active_p will always be true for glibc (and the
weak symbols won't be needed anyway).