This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 2.25 freeze status
- From: Carlos O'Donell <carlos at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, Florian Weimer <fweimer at redhat dot com>, Phil Blundell <pb at pbcl dot net>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Date: Thu, 2 Feb 2017 16:04:19 -0500
- 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>
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.
As you noted bug 21041 will remain open to handle the real problem in the 2.26 timeframe.
--
Cheers,
Carlos.