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 11:00 AM, H.J. Lu <> wrote:
> 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
> 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.

I will add a linker switch, -z extern-protected-data, to control
linker behavior.


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