2.25 freeze status

H.J. Lu hjl.tools@gmail.com
Thu Feb 2 18:07:00 GMT 2017


On Thu, Feb 2, 2017 at 5:02 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 02/01/2017 12:04 PM, H.J. Lu wrote:
>> On Tue, Jan 31, 2017 at 12:45 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> Solutions:
>>>
>>> (a) Revert the changes to libpthread which introduced the longjmp IFUNC.
>>>
>>> (b) Revert the fix for bug 20019 which stops the affected applications from
>>>     starting.
>>
>> It just silently ignores the potential crash when longjmp is called.  I won't
>> call it a solution.
>
>>> (c) Implement IFUNC relocation ordering such that the applications work
>>>     correctly in the presence of the libpthread longjmp IFUNC.
>>>
>>> Florian Weimer has stated that (c) is not ready for glibc 2.25 release which
>>> is tomorrow.
>>
>> d)
>>
>> Remove IFUNC from libpthread.so.   The requirement for that the symbol
>> definition at run-time must come from the same shared object at link-time
>> is questionable.
>
> Which of (b) or (d) do you interpret to be less risk given the upcoming release?
>
> Keeping in mind the success criteria defined earlier for this consensus discussion:
>
> * Release of glibc 2.25 without the side effect caused by the fix for 20019
>   which prevents potentially valid applications from starting.
>
> This is a time-boxed release. We can delay a fix. Incremental progress is OK.
>

This is what I propose for 2.25.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-IFUNC-relocation-against-unrelocated-shared-li.patch
Type: text/x-patch
Size: 1933 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170202/74063083/attachment.bin>


More information about the Libc-alpha mailing list