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 10:06 AM, Pedro Alves <palves@redhat.com> wrote:
> On 03/27/2015 04:54 PM, H.J. Lu wrote:
>> On Fri, Mar 27, 2015 at 9:43 AM, Pedro Alves <palves@redhat.com> wrote:
>>> On 03/27/2015 04:40 PM, H.J. Lu wrote:
>>>> On Fri, Mar 27, 2015 at 9:38 AM, Pedro Alves <palves@redhat.com> wrote:
>>>
>>>>> Urgh.  The glibc issue sounds the most alarming.  If we can't keep
>>>>> back compatibility, isn't there a new bit/attribute we can put
>>>>> somewhere to tag new binaries with protected symbols in a
>>>>> way that existing systems just error out when loading them?
>>>>
>>>>
>>>> There is no backward compatibility to speak with since protected
>>>> data symbol never worked before.
>>>
>>> OK, but when it's all fixed, programs and libraries will start
>>> using the feature.  It'd be best if such programs/libraries just
>>> failed to load in older systems, than crash or corrupt data at random.
>>>
>>
>> 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.


-- 
H.J.


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