This is the mail archive of the libc-alpha@sourceware.org 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] nptl: Open libgcc.so with RTLD_NOW during pthread_cancel


On 01/10/2018 11:20 AM, Florian Weimer wrote:
> On 01/10/2018 08:09 PM, Carlos O'Donell wrote:
>> On 01/10/2018 02:49 AM, Florian Weimer wrote:
>>> Disabling lazy binding reduces stack usage during unwinding.
>>>
>>> Note that RTLD_NOW only makes a difference if libgcc.so has not
>>> already been loaded, so this is only a partial fix.
>>>
>>> 2018-01-10  Florian Weimer  <fweimer@redhat.com>
>>>
>>>     [BZ #22636]
>>>     * sysdeps/nptl/unwind-forcedunwind.c (pthread_cancel_init): Open
>>>     libgcc.so with RTLD_NOW, to avoid lazy binding during unwind.
>>>
>>> diff --git a/sysdeps/nptl/unwind-forcedunwind.c b/sysdeps/nptl/unwind-forcedunwind.c
>>> index ab4350de99..67b8e74b53 100644
>>> --- a/sysdeps/nptl/unwind-forcedunwind.c
>>> +++ b/sysdeps/nptl/unwind-forcedunwind.c
>>> @@ -49,7 +49,7 @@ pthread_cancel_init (void)
>>>         return;
>>>       }
>>>   -  handle = __libc_dlopen (LIBGCC_S_SO);
>>> +  handle = __libc_dlopen_mode (LIBGCC_S_SO, RTLD_NOW | __RTLD_DLOPEN);
>>>       if (handle == NULL
>>>         || (resume = __libc_dlsym (handle, "_Unwind_Resume")) == NULL
>>>
>>
>> Should we not also do this for sysdeps/gnu/unwind-resume.c ?
> 
> Interesting.
> 
> _Unwind_Resume is only called from a landing pad after unwinding has
> already begun, so the code never actually loads libgcc_s, and
> RTLD_NOW does not have any effect at this point (even with lazy
> binding, most of the unwinder will already have been bound by this
> point).  In contrast, the nptl unwinding code used by
> pthread_exit/pthread_cancel actually initiates unwinding.
> 
> There is certainly a cleanup opportunity here, but changing the
> dlopen flags is not needed at this point.
What I want to avoid is two similar pieces of code that do distinct
things. Is there any reason we shouldn't just checkin a change here
that makes both the same, thus avoiding differences?

-- 
Cheers,
Carlos.


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