This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PR 18167, Relax PR 15228 protected visibility restriction
- From: Pedro Alves <palves at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Fri, 27 Mar 2015 18:29:42 +0000
- Subject: Re: PR 18167, Relax PR 15228 protected visibility restriction
- Authentication-results: sourceware.org; auth=none
- References: <20150327054327 dot GB26234 at bubble dot grove dot modra dot org> <551531AA dot 1060006 at redhat dot com> <20150327122941 dot GC26234 at bubble dot grove dot modra dot org> <55158778 dot 8050009 at redhat dot com> <CAMe9rOrZB+kuDd-Z0hx-EMiZO=c2tG3J7gQH1JpNe_gHGSUBKA at mail dot gmail dot com> <551588C6 dot 9080004 at redhat dot com> <CAMe9rOoZPSLL0OOokyFEsDiCs8ey5tYNUx3fhXRhjJGokW5PFg at mail dot gmail dot com> <55158E28 dot 3010207 at redhat dot com> <CAMe9rOq1R7ma7s+r1bn5yWyzUq3y4Wt2OwW7iQ0m=O02ioWQzw at mail dot gmail dot com> <CAMe9rOr5LUgfDJ_wKwW=KW1ckTuZiDEKcqt=8_QLDjCifMh4nQ at mail dot gmail dot com> <551595E8 dot 1010300 at redhat dot com> <CAMe9rOp5HkcowDHd_eV9oVD=SN76rUKtewqQy2nA360+peowaA at mail dot gmail dot com> <55159B20 dot 9050505 at redhat dot com> <CAMe9rOpp8bZbzX29PXuroz0_6+hOgi2mrbqKLmTJEC3-synHqQ at mail dot gmail dot com>
On 03/27/2015 06:13 PM, H.J. Lu wrote:
> On Fri, Mar 27, 2015 at 11:02 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 03/27/2015 05:56 PM, H.J. Lu wrote:
>>> On Fri, Mar 27, 2015 at 10:39 AM, Pedro Alves <palves@redhat.com> wrote:
>>>> On 03/27/2015 05:25 PM, H.J. Lu wrote:
>>>>> On Fri, Mar 27, 2015 at 10:09 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>> On Fri, Mar 27, 2015 at 10:06 AM, Pedro Alves <palves@redhat.com> wrote:
>>
>>>>>>>> If one of gcc, glibc or binutils isn't fixed, the program may misbehave.
>>>>>>>> I don't know how it be avoided at run-time with fixing all 3.
>>>>>>>
>>>>>>> I'm not really worried about gcc or binutils. Those are easy to
>>>>>>> update. The issue is picking a binary that was built against fixed
>>>>>>> gcc and binutils, and then running it on an system that happens to
>>>>>>> not have glibc fixed. That just seems like ABI breakage.
>>>>>>>
>>>>>>> How about emitting a reference to a symbol that only fixed glibc
>>>>>>> provides?
>>>>>>
>>>>>> It is easy to verify. Stay tuned.
>>>
>>> Yes, the program will misbehave if the run-time glibc isn't
>>> fixed.
>>
>> OK. I'm a bit confused now. Are you going to try the idea
>> suggested above?
>
> No. There is nothing to try. You can't fix the old binary. The
> new glibc works with the old binary.
But I've been talking about the opposite all along. Let
me reiterate.
When protected visibility variables are fixed in gcc and binutils,
programs and libraries will start making use of the feature, well,
because it now works. While before, people didn't make
use of the feature.
Because of that, I'm arguing that it's important that programs
that reference protected variables built with new gcc/binutils,
fail to load with old glibc, instead of misbehaving randomly.
Thus the idea of making new gcc/ld have new programs reference a
symbol that only new glibc provides, so that old glibc can't
satisfy it and thus new programs with old glibc just don't run
at all. Or something along else those lines: some elf bit;
some attribute; something.
Thanks,
Pedro Alves
- References:
- PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction
- Re: PR 18167, Relax PR 15228 protected visibility restriction