| Message ID | 64b3ba1c-185a-73a5-1669-a23fa04ddeab@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | musl: Don't use gthr weak refs in libgcc PR91737 | expand |
On 11/15/19 3:00 AM, Szabolcs Nagy wrote: > The gthr weak reference based single thread detection is unsafe with > static linking and in case of dynamic linking it's ineffective on musl > since pthread symbols are defined in libc.so. > > Ideally this should be fixed for all targets, since glibc plans to move > libpthread.so into libc.so too and users want to static link to pthread > without --whole-archive: PR87189. > > For now we have to explicitly opt out from the broken behaviour in the > config machinery of each target lib and libgcc was previously missed. > > libgcc/ChangeLog: > > 2019-11-15 Szabolcs Nagy <szabolcs.nagy@arm.com> > > * config.host: Add t-gthr-noweak on *-*-musl*. > * config/t-gthr-noweak: New file. > Given the patch is constrained to musl, it's obviously OK. WRT the bigger question, even if glibc gets those bits moved into libc.so it's likely going to be a long time before the split between libc and libpthreads disappears from the wild :( jeff
On Sun, Nov 17, 2019 at 11:31:02AM -0700, Jeff Law wrote: > On 11/15/19 3:00 AM, Szabolcs Nagy wrote: > > The gthr weak reference based single thread detection is unsafe with > > static linking and in case of dynamic linking it's ineffective on musl > > since pthread symbols are defined in libc.so. > > > > Ideally this should be fixed for all targets, since glibc plans to move > > libpthread.so into libc.so too and users want to static link to pthread > > without --whole-archive: PR87189. > > > > For now we have to explicitly opt out from the broken behaviour in the > > config machinery of each target lib and libgcc was previously missed. > > > > libgcc/ChangeLog: > > > > 2019-11-15 Szabolcs Nagy <szabolcs.nagy@arm.com> > > > > * config.host: Add t-gthr-noweak on *-*-musl*. > > * config/t-gthr-noweak: New file. > > > Given the patch is constrained to musl, it's obviously OK. > > WRT the bigger question, even if glibc gets those bits moved into > libc.so it's likely going to be a long time before the split between > libc and libpthreads disappears from the wild :( The right thing for GCC to do on the glibc side is just having the affected target libs depend on libpthread until the symbols are moved. With the current invalid use of weak refs, static linking of multithreaded programs is completely broken on glibc, and distros are resorting to hacks of using ld -r or similar to move all of libpthread.a into a monolithic object file to work around it. In any case, I'll be happy to have it fixed just for musl now, so we can drop these patches on our side and have upstream GCC working pretty much out of the box. Rich
diff --git a/libgcc/config.host b/libgcc/config.host index 122113fc519..fe1b9ab93d5 100644 --- a/libgcc/config.host +++ b/libgcc/config.host @@ -1500,3 +1500,10 @@ aarch64*-*-*) tm_file="${tm_file} aarch64/value-unwind.h" ;; esac + +case ${host} in +*-*-musl*) + # The gthr weak references are unsafe with static linking + tmake_file="$tmake_file t-gthr-noweak" + ;; +esac diff --git a/libgcc/config/t-gthr-noweak b/libgcc/config/t-gthr-noweak new file mode 100644 index 00000000000..45a21e9361d --- /dev/null +++ b/libgcc/config/t-gthr-noweak @@ -0,0 +1,2 @@ +# Don't use weak references for single-thread detection +HOST_LIBGCC2_CFLAGS += -DGTHREAD_USE_WEAK=0