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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Fri, 27 Mar 2015 13:04:22 -0700
- 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> <5515A196 dot 4070403 at redhat dot com> <CAMe9rOp9YTHdgy38peMLnj5FVi9zJSN=p5Q_m0YNe8HC7bQJ-g at mail dot gmail dot com> <5515ADB2 dot 9090600 at redhat dot com>
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.
- 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
- 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