[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Andrew Pinski --- Fixed: https://gcc.gnu.org/pipermail/gcc-cvs/2024-April/401301.html
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Andrew Pinski changed: What|Removed |Added CC||punitb20 at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 109540 has been marked as a duplicate of this bug. ***
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Andrew Pinski changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 114646 has been marked as a duplicate of this bug. ***
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Andrew Pinski changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #7 from Andrew Pinski --- *** Bug 87189 has been marked as a duplicate of this bug. ***
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Jonathan Wakely 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 --- (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 *) _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).
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017
Ben Longbons changed:
What|Removed |Added
CC||b.r.longbons at gmail dot com
--- Comment #5 from Ben Longbons ---
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
#include
#include
#include
int main(void)
{
void *libpthread = dlopen(LIBPTHREAD_SO, RTLD_LAZY);
assert (libpthread);
assert (__gthread_active_p());
}
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 --- Comment #4 from nsz at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) > There are other reasons why using static libraries does not make sense for > libpthread. i can't immediately think of any, can you give a hint?
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 --- Comment #3 from Andrew Pinski --- There are other reasons why using static libraries does not make sense for libpthread.
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 --- Comment #2 from nsz at gcc dot gnu.org --- i see the glibc threads linked from https://sourceware.org/bugzilla/show_bug.cgi?id=5784 but there are other libcs with static linking support, so even if weakrefs worked on glibc (now they don't) this would be a gcc bug on other targets.. when this came up with musl libc it required fair amount of debugging and i see other cases where people spent time on this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960 so i think it is worth changing the logic.
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 --- Comment #1 from Andrew Pinski --- IIRC this was declared a libc bug or an user error (not using the full archive). There is another thread on the glibc side if you want to read up on that.
