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

[Alan Modra <amodra at gmail dot com>]

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.

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

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.

-- 
Alan Modra
Australia Development Lab, IBM