This is the mail archive of the binutils@sourceware.org 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: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.


-- 
H.J.


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