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 11:00:09 -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>
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.