Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sun, Feb 25, 2018 at 6:13 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * H. J. Lu:
>
>> On Sun, Feb 25, 2018 at 5:49 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>>> * H. J. Lu:
>>>
>>>> On Sun, Feb 25, 2018 at 5:31 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>>>>> * H. J. Lu:
>>>>>
>>>>>> libpthread cancellation implementation passes cancel_jmp_buf to
>>>>>> libgcc unwinder,
>>>>>
>>>>> Oh.  Where does it do that?  If you mean _Unwind_ForcedUnwind, I think
>>>>> that's just an opaque closure argument for the callback.
>>>>
>>>> Yes.  Libgcc unwinder needs to deal with it.
>>>
>>> Please point me to the code.  Thanks.
>>
>> sysdeps/nptl/unwind-forcedunwind.c has
>>
>> _Unwind_Reason_Code
>> _Unwind_ForcedUnwind (struct _Unwind_Exception *exc, _Unwind_Stop_Fn stop,
>>       void *stop_argument)
>> {
>>   if (__glibc_unlikely (libgcc_s_handle == NULL))
>>     pthread_cancel_init ();
>>   else
>>     atomic_read_barrier ();
>>
>>   _Unwind_Reason_Code (*forcedunwind)
>>     (struct _Unwind_Exception *, _Unwind_Stop_Fn, void *)
>>     = libgcc_s_forcedunwind;
>>   PTR_DEMANGLE (forcedunwind);
>>   return forcedunwind (exc, stop, stop_argument);
>> }
>
> Thanks.  I think stop_argument ends up in the private_2 member inside
> unwind.inc, which is only passed back to the callback (the stop
> function pointer) in _Unwind_ForcedUnwind_Phase2, and not interpreted
> by libgcc itself.  So this shouldn't be a problem.

Please take a look at hjl/setjmp/cancel branch:

https://github.com/hjl-tools/glibc/tree/hjl/setjmp/cancel

Functions, like LIBC_START_MAIN, START_THREAD_DEFN as well as these
with thread cancellation, call setjmp, but never return to their
callers after longjmp returns.  This patch adds <bits/setjmp-cancel.h>
and <setjmp-cancelP.h> to provide a version of setjmp family functions,
__setjmp_cancel and __sigsetjmp_cancel, which are used to implement
thread cancellation.  The default __setjmp_cancel and __sigsetjmp_cancel
are defined as setjmp and __sigsetjmp, respectively, which are the same
as before.

On x86, a different version is added to avoid saving and restoring
shadow stack register.  __libc_longjmp, which is a private interface
for cancellation implementation in libpthread, is changed to call
__longjmp_cancel instead of __longjmp.

This leaves cancel_jmp_buf unchanged.  But is it worth it?

1. I have to add  __setjmp_cancel and __sigsetjmp_cancel which won't
save and restore shadow stack register.
2. I still need yet to add the new version of __sigsetjmp for older binaries.
3, Older .o files compiled against glibc 2.27 are still incompatible with
glibc 2.28.

-- 
H.J.