This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Sun, Feb 25, 2018 at 6:13 AM, Florian Weimer <> wrote:
> * H. J. Lu:
>> On Sun, Feb 25, 2018 at 5:49 AM, Florian Weimer <> wrote:
>>> * H. J. Lu:
>>>> On Sun, Feb 25, 2018 at 5:31 AM, Florian Weimer <> 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
>, 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:

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]