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

["nsz at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 78017
           Summary: weak reference usage in gthr-posix.h (__gthread*) is
                    broken
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          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
https://gcc.gnu.org/ml/libstdc++/2014-11/msg00122.html

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

  std::mutex m;
  m.lock();
  dlopen(.. something that starts threads and use m ..)
  m.unlock();


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.