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