pthread_cancel async-signal-safe
Adhemerval Zanella
adhemerval.zanella@linaro.org
Mon Dec 7 13:02:34 GMT 2020
On 04/12/2020 15:32, Joseph Myers wrote:
> On Fri, 4 Dec 2020, Adhemerval Zanella via Libc-alpha wrote:
>
>> For 1. I don't see a easier solution without moving pthread_cancel_init
>> to out of pthread_cancel and this has its own drawbacks (by always
>> forcing loading libgcc_s.so when libpthread is linked).
>
> libgcc_s.so should indeed be loaded on startup (loading it later has the
> problem of introducing failures, if loading fails, in a context where
> failures aren't expected).
Indeed, it might be required to even loading it early as pthread_cancel
currently does or just add libgcc_s.so in DT_NEEDED for at least
libpthread (and once we move all libpthread implementation to libc.so
it will make programs always load libgcc_s.so).
>
>> Maybe linking libgcc_s.a statically with libpthread and remove the
>> dynamic loading of libgcc_s.so? I am not sure of this implication
>> of this strategy.
>
> I'd expect bootstrapping problems, and possibly also problems working with
> unwind information coming from newer GCC versions than the one libgcc_eh.a
> came from.
>
> We have a long comment in Makeconfig about linking with libgcc.
>
Indeed this does not seems the best option, neither packing our own unwinder
since it will have the inherent unwind information mismatch issues.
The pthread_cancel interoperability with C++ seems a heavy burden, but I'm
not sure which better options we do have here.
More information about the Libc-alpha
mailing list