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

[H.J. Lu]

On Fri, Apr 10, 2015 at 4:52 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Apr 10, 2015 at 11:00 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> 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.
>
> I will add a linker switch, -z extern-protected-data, to control
> linker behavior.
>

Here is a patch to add such an option.  OK for master?

Thanks.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-z-no-extern-protected-data-to-ld.patch
Type: text/x-patch
Size: 8256 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20150411/65f66de9/attachment.bin>