This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 2.25 freeze status
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Phil Blundell <pb at pbcl dot net>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Date: Thu, 2 Feb 2017 13:15:37 -0800
- Subject: Re: 2.25 freeze status
- Authentication-results: sourceware.org; auth=none
- References: <c4cfc6e1-ff9f-c8b3-4a56-38f8d484aa05@gotplt.org> <22163768-023c-1ed5-b258-6e6d14f45e01@redhat.com> <CAMe9rOovpWzNv7TQ3Emj+Ns8hoD9gf8jKNHnStCZfsM=gzrXdw@mail.gmail.com> <eba4d0d3-ead2-c166-af3a-51d3450529d6@redhat.com> <CAMe9rOo7c_G3Gc1jxX_5gUnncQKa4dK1LU4gddGXypCVA+F9MQ@mail.gmail.com> <e76eec7d-d357-bc3c-fcbb-c32abb6b401f@redhat.com> <CAMe9rOrfWP1oDhZ5uRx226jbJsXuXp7qD2844t5da3ub57r=vA@mail.gmail.com> <ea6efe90-2b68-5eef-72f0-0d9a668a3616@redhat.com> <CAMe9rOoYDKNuqLPuJs4ssPbaoU2FKirERvNopJKp9eT-p7_=Yg@mail.gmail.com> <CAMe9rOpHJxopCOUyw22VEZjPvv61Wr+0s02voAa3zf_aSW8oog@mail.gmail.com> <87a50e42-3e86-3f4a-d470-46393e2af199@redhat.com> <CAMe9rOotk606nxvkvYcrF4hkhFTqgaS=Et0kAWkPsK+DiHCWcA@mail.gmail.com> <7c124a2b-a82d-4761-7018-d1a488bc1033@redhat.com> <CAMe9rOrioqW4UmzJzi_3qGG0toKka4zC6jazSbNeEDzcOXu-7w@mail.gmail.com> <799438bb-9570-9b2b-b67b-9a704142daf3@redhat.com> <CAMe9rOoS=DhUp7qiMS=Haz3x2jHBO7+t2eJxQGYvd+pKm_SnNA@mail.gmail.com> <ef8a6a91-2688-9af3-7f34-946c6ad76ff2@redhat.com>
On Thu, Feb 2, 2017 at 1:04 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 02/02/2017 01:07 PM, H.J. Lu wrote:
>> 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.
>
> I agree with your proposal. It meets the success criteria.
>
> Issuing an error but allowing the program to start is an excellent compromise.
>
> We currently print errors for failing to preload objects, and many of the machine
> backends print errors for relocation problems encountered during dynamic linking
> (x86_64: overflows and copy relocs where the size has changed).
>
> I agree that this situation is very similar to those and so the use of _dl_error_printf
> instead of _dl_fatal_printf is a good idea.
>
> Please commit your change and we'll mark this issue complete for 2.25.
Done. Thanks.
> As you noted bug 21041 will remain open to handle the real problem in the 2.26 timeframe.
>
> --
> Cheers,
> Carlos.
--
H.J.