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

[Alan Modra <amodra at gmail dot com>]

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.

-- 
Alan Modra
Australia Development Lab, IBM