Re: Downgrade linker error on protected symbols in .dynbss to a warning

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Apr 10, 2015 at 7:59 AM, Alan Modra <amodra@gmail.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 <amodra@gmail.com> 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
> checks.
>
> 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
> correctness.

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
library.

> 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.

-- 
H.J.