https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737
nsz at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |NEW
Last reconfirmed| |2019-09-17
CC| |nsz at gcc dot gnu.org
Resolution|MOVED |---
Ever confirmed|0 |1
--- Comment #5 from nsz at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> Glibc has a similar bug and been discussed how to fix it.
> The way Glibc is going to fix it (though it has not yet) is that
> libpthread.a will be really just include one object file which includes all
> of the pthread library.
citation needed.
the plan in glibc is to provide a "is single threaded" api.
https://sourceware.org/ml/libc-alpha/2019-08/msg00438.html
once that's in then in principle any library (like libstdc++)
can do single thread optimizations without hacks.
(another glibc plan is to move libpthread.so into libc.so
so there are no awkward internal abis between them and then
avoiding pthread dependency is no longer relevant.)
i think that should work for the unwinder in libgcc too.
on the musl side, we want to disable this hack before that
happens, it's better to not do any single thread optimizations
than silently breaking things.
so the right fix is something equivalent to
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222329
i.e. libgcc should be compiled with GTHREAD_USE_WEAK=0 on *musl*.
