Bug ID: 78017
Summary: weak reference usage in gthr-posix.h (__gthread*) is
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
there seem to be no open bug for the issue discussed in
i think libstdc++, libgfortran and libgcov are affected.
libgcc/gthr-posix.h uses weak references for the pthread api to
1) detect single-threadedness
2) use pthread api without adding -lpthread dependency.
this does not work
a) with static linking:
because 1) fails on the target:
single threaded execution can be assumed if pthread_create and
thrd_create are not referenced (on targets without libpthread
dlopen support), but the gthr logic only checks pthread_create
(on bionic) or pthread_cancel (on some targets as a misguided
attempt to avoid detecting threads because of ldpreloaded pthread
wrappers which "seem unlikely" to define pthread_cancel).
symbols required by libstdc++ may be missing because of 2),
(causing hard to debug runtime crashes):
redhat puts all of libpthread into a single .o, others use
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive
linker flags as a workaround, but this should not be needed:
if libstdc++.a semantically requires strong references then
those references must be strong (the calls may be elided
using the detection above).
b) if there is dlopen support for libpthread
then single-threadedness can change at runtime, so any check
would break code like
dlopen(.. something that starts threads and use m ..)
various targets explicitly opt out from the weak ref hacks,
(using gcc configure time hacks), i think instead the gthr
logic should be safe by default:
assume multi-threaded execution by default and only try
to optimize the single threaded case when it is guaranteed
to be safe.