This is the mail archive of the mailing list for the binutils 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: PR 18167, Relax PR 15228 protected visibility restriction

On Fri, Mar 27, 2015 at 11:29 AM, Pedro Alves <> wrote:
> On 03/27/2015 06:13 PM, H.J. Lu wrote:
>> On Fri, Mar 27, 2015 at 11:02 AM, Pedro Alves <> wrote:
>>> On 03/27/2015 05:56 PM, H.J. Lu wrote:
>>>> On Fri, Mar 27, 2015 at 10:39 AM, Pedro Alves <> wrote:
>>>>> On 03/27/2015 05:25 PM, H.J. Lu wrote:
>>>>>> On Fri, Mar 27, 2015 at 10:09 AM, H.J. Lu <> wrote:
>>>>>>> On Fri, Mar 27, 2015 at 10:06 AM, Pedro Alves <> 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.

This feature has been used today as shown in PR 18167.
I don't see a way to make GCC/binutils require a specific
version of glibc to use it.


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