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 12:21 PM, Pedro Alves <palves@redhat.com> wrote:
> On 03/27/2015 07:12 PM, H.J. Lu wrote:
>>> > 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.
>
> So skip the requirement under the same conditions Alan
> skipped the linker check in this PR18167 patch, otherwise,
> enforce it?

Linker doesn't look into the instruction sequence in a DSO.
It has no idea if a DSO is OK or not, especially when only
run-time DSO matters.


-- 
H.J.


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