This is the mail archive of the
mailing list for the binutils project.
Re: Downgrade linker error on protected symbols in .dynbss to a warning
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Binutils <binutils at sourceware dot org>, Richard Henderson <rth at redhat dot com>
- Date: Fri, 10 Apr 2015 16:52:59 -0700
- Subject: Re: Downgrade linker error on protected symbols in .dynbss to a warning
- Authentication-results: sourceware.org; auth=none
- References: <20150410094542 dot GL27812 at bubble dot grove dot modra dot org> <CAMe9rOq5nPMRZTm02feeWF1FY8FR7u1T5JGGzChzNM0mH-VHmQ at mail dot gmail dot com> <20150410115859 dot GM27812 at bubble dot grove dot modra dot org> <CAMe9rOrppvHdxMm-3x=7XaJQzW50dT4jkO-DRWRJxYhTtU6OPw at mail dot gmail dot com> <20150410132126 dot GN27812 at bubble dot grove dot modra dot org> <CAMe9rOrMJMvcqaPG0wRyY5O0Q_WC=-DBrZwOJboS_5Otw3Y5GA at mail dot gmail dot com> <20150410145906 dot GO27812 at bubble dot grove dot modra dot org> <CAMe9rOoU=pCmLVL5-snT6LgAXzFL0mBQAxwoSOqENDUyg8jhOA at mail dot gmail dot com>
On Fri, Apr 10, 2015 at 11:00 AM, H.J. Lu <firstname.lastname@example.org> wrote:
> On Fri, Apr 10, 2015 at 7:59 AM, Alan Modra <email@example.com> wrote:
>> On Fri, Apr 10, 2015 at 06:39:10AM -0700, H.J. Lu wrote:
>>> On Fri, Apr 10, 2015 at 6:21 AM, Alan Modra <firstname.lastname@example.org> wrote:
>>> > On Fri, Apr 10, 2015 at 05:49:05AM -0700, H.J. Lu wrote:
>>> >> GCC 5 is no more wrong than before with older glibc.
>>> > This is false. Your gcc5 change with glibc 2.22 fixes just one
>>> > particular use of protected visibility variables, a definition in a
>>> > shared library and a reference in a non-PIC executable.
>>> > Previous versions of gcc work properly with glibc-2.21 and earlier for
>>> > - more than one shared library with definitions of a protected
>>> > visibility variable,
>>> > - a shared library with a definition of a protected variable, and an
>>> > executable with a definition of the same variable.
>>> > Those cases are both broken with gcc-5 and glibc-2.21, on x86.
>>> It is broken only if a shared library expects that the protected definition
>>> won't be preempted by another definition.
>> If you don't require protected visibility variables to behave as they
>> are supposed to behave, then of course everything is fine.
>>> > Note that I'm not against the overall idea of your changes. In fact,
>>> > I think the idea is quite reasonable. What I'm complaining about is
>>> > the complete lack of any checking for older glibc in the case of the
>>> > gcc change, and lack of checks for older gcc in the binutils change.
>>> We need to start somewhere. Otherwise, it will never be fixed.
>> Maybe, but you should admit that without the checks you have broken
>> the toolchain. When one part of the toolchain requires other parts to
>> change for correct behaviour we usually at least want configure
>> Your gcc change ought to have emitted an attribute or somesuch into
>> relocatable object files marking them as having protected visibility
>> variables **with code accessing them no different than that for
>> default visibility variables**. That change requires glibc-2.22 for
> GCC, glibc and binutils were never correct before. If applications
> depend on the correct behavior of protected data symbol, they should
> update GCC, glibc and binutils.
>> The attribute could then be copied to a note when building a shared
>> library, and also be used by the linker to warn if linking with an
>> older ld.so. The note then could be used by the linker to disable
>> "copy reloc against protected <symbol> is dangerous".
> This won't work since link-time shared library != run-time shared
>> Ideally, it would also be possible to disable your gcc change with
>> configury and command line options, for people with older systems who
>> want to upgrade gcc but not glibc.
> If they care about correctness of protected data symbol, they
> should update GCC, glibc and binutils.
I will add a linker switch, -z extern-protected-data, to control