pthread_cancel async-signal-safe

[Adhemerval Zanella]

On 07/12/2020 10:33, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 07/12/2020 10:06, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> The pthread_cancel interoperability with C++ seems a heavy burden, but I'm
>>>> not sure which better options we do have here.
>>>
>>> It's not just C++, it's needed for -fexception support in C and other
>>> languages.
>>>
>>> Furthermore, the out-of-line DWARF unwinding tables can be made
>>> considerably safer than on-stack pointers used by the longjmp-based
>>> mechanism.
>>
>> Do you mean for pthread_cleanup_push? I do agree, but I haven't check exactly
>> what need to be done to accomplish neither it if would be be possible to
>> accomplish for !_GNU case.  So do you think packing an unwinder on glibc
>> could be an improvement?  If so, which would be possible issues?
> 
> I think the issues are largely political (renegotiating the GCC vs glibc
> split).

So what do you suggest to progress in the stalemate or the fix to require
adequate an improve glibc pthread cancellation (which is plagued with
diverse issues)?

We might try to copy gcc current unwinder code and avoid loading libgcc_so,
it should fix the async-signal-safe issue and improve the possible failures
trying to load libgcc_s.so late.  If I recall correctly from your Caudron
presentation, gcc developers are not willing neither plan to actually use
glibc unwinder; so it would be used solely for our own use (at first).