pthread_cancel async-signal-safe

[Florian Weimer]

* 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).

I think the unwinder question should not block fixing other issues that
aren't directly related to async-signal-safety of the pthread_cancel
call.

The GCC unwinder has its own set of async-signal-safety issues, so the
dlopen call really isn't the only problem here.  It also means that just
copying the code isn't going to fix much at this point.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill