* Andreas Schwab: > On Apr 27 2021, Florian Weimer via Binutils wrote: > >> I think we can provide an libBrokenGnulib.so preload module which >> defines pthread_mutexattr_gettype to zero (as an absolute address), so >> there is a kludge to keep old binaries working, but this is really >> something that must be fixed in gnulib. > > It is likely that the use of weak pthread symbols is not confined to > gnulib.
True. Here's a fairly representative test case, I think. #include <pthread.h> #include <stdio.h> extern __typeof (pthread_key_create) __pthread_key_create __attribute__ ((weak)); extern __typeof (pthread_once) pthread_once __attribute__ ((weak)); void f1 (void) { puts ("f1 called"); } pthread_once_t once_var; void __attribute__ ((weak)) f2 (void) { if (__pthread_key_create != NULL) pthread_once (&once_var, f1); } int main (void) { f2 (); } Building it with “gcc -O2 -fpie -pie” and linking with binutils 2.30 does not result in a crash with LD_PRELOAD=libpthread.so.0. That's because the call-to-address-zero via pthread_once has been stubbed out with NOPs, I think. This is still not correct and will undoubtedly cause problems because pthread_once is usually called for its side effect. With binutils 2.35, the call-to-address-zero is not stubbed out anymore, but there is still no dynamic symbol reference for pthread_once, so there is a crash when running with LD_PRELOAD=libpthread.so.0. This looks like a pre-existing toolchain issue on POWER, related to the thread I quoted at the start. If we proceed with the glibc libpthread changes as planned, things might turn out unacceptably bad. I did a quick experiment and we cannot work around this using a libpthread.so stub library and compatibility-only symbols in libc.so.6. Unversioned weak symbols bind to the baseline symbol version, as they probably should. Even a __pthread_key_create@GLIBC_2.17 compatibility symbol triggers this issue. I have to think of something else to salvage this. Thanks, Florian