This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Fri, Apr 10, 2015 at 7:59 AM, Alan Modra <> 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 <> 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  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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]