https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017
Ben Longbons <b.r.longbons at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |b.r.longbons at gmail dot com
--- Comment #5 from Ben Longbons <b.r.longbons at gmail dot com> ---
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.
Note that plugins that indirectly pull in pthreads are very common in the wild.
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 had falsely assumed the only danger was doing the dlopen while any lock is
held, leading to mismatched lock/unlock pairs, which would be fairly easy to
avoid)
Tested on Debian 10 (buster), with:
g++ (Debian 8.3.0-6) 8.3.0
GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.
GNU ld (GNU Binutils for Debian) 2.31.1
// link with -ldl
#include <gnu/lib-names.h>
#include <assert.h>
#include <dlfcn.h>
#include <bits/gthr.h>
int main(void)
{
void *libpthread = dlopen(LIBPTHREAD_SO, RTLD_LAZY);
assert (libpthread);
assert (__gthread_active_p());
}
