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

H.J. Lu hjl.tools@gmail.com
Tue Apr 14 11:16:00 GMT 2015


On Mon, Apr 13, 2015 at 7:09 PM, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Apr 13, 2015 at 04:55:47AM -0700, H.J. Lu wrote:
>> On Sun, Apr 12, 2015 at 8:32 PM, Alan Modra <amodra@gmail.com> wrote:
>> > On Sat, Apr 11, 2015 at 08:27:58AM -0700, H.J. Lu wrote:
>> >> On Fri, Apr 10, 2015 at 4:52 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> >> > 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?
>> >
>> > Why is this option needed?
>> >
>>
>> To work around the GCC bug.  Otherwise, we got
>>
>> [hjl@gnu-tools-1 pr17709]$ cat bar.c
>> int a;
>>
>> __attribute__((visibility("protected"))) int a;
>>
>> void
>> bar ()
>> {
>>   a = 30;
>> }
>> [hjl@gnu-tools-1 pr17709]$ make libbar.so
>> gcc  -m32 -fPIC   -c -o bar.o bar.c
>> ./ld -m elf_i386 -shared -o libbar.so bar.o
>> ./ld: bar.o: relocation R_386_GOTOFF against protected data `a' can
>> not be used when making a shared object
>
> I presume this isn't gcc-5.  So for code generated by older versions
> of gcc you now emit an error when linking shared libraries that access
> protected visibility variables?  And the reason you emit an error when
> building the shared library is that you'd like everyone to use gcc-5?
>
> I really dislike the way this whole saga is playing out.  Especially
> since you know that there is absolutely nothing wrong with using
> R_386_GOTOFF against protected visibility data.  In fact, code using a
> relative access is more efficient, and I wouldn't be surprised if
> someone raises a gcc-5 regression over *not* using R_386_GOTOFF in a
> shared library making heavy use of protected visibility.
>
> If you want to go ahead with this patch, you need to make it x86
> specific.  -z extern-protected-data is not appropriate as a general
> ld option.
>

This is what I checked in.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-z-noextern-protected-data-to-ld-for-ELF-x86.patch
Type: text/x-patch
Size: 14896 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20150414/3fcd040c/attachment.bin>


More information about the Binutils mailing list