RFC: Properly handle protected data symbol with copy relocation

["H. J. Lu" <hjl at lucon dot org>]

On Thu, Jan 20, 2005 at 10:45:13PM -0800, H. J. Lu wrote:
> On Fri, Jan 21, 2005 at 01:26:06AM -0500, Ian Lance Taylor wrote:
> > "H. J. Lu" <hjl@lucon.org> writes:
> > 
> > > Avoid copy relocation leads to writable text section on ia32. I am not
> > > sure that generate writable text section without -z nocopyreloc is a
> > > good idea.
> > 
> > I don't see why it is better to prevent the user from generating an
> > executable at all.
> > 
> > What this is really leading up to is that it is unwise for a shared
> > library to declare a global variable to be protected.  Doing that
> > makes it costly for the main executable to refer to that global
> > variable.
> > 
> > But if a shared library does declare a global variable to be
> > protected, and if the main executable does refer to it, I think we
> > should attempt to support that.  I don't see why we should simply
> > reject it and make it impossible to use the shared library in that
> > way.  We could perhaps issue a warning in that case.
> 
> I see. For ia32, we can issue a warning when generating such a shared
> library and generate writable text section when it is referenced by
> main executable.
> 
> 
> > 
> > > I don't think -z nocopyreloc works on x86_64.
> > 
> > Can it be fixed, or is there some reason that it is impossible?
> > 
> 
> I think it has something to do with the psABI and Linux runtime,
> something like relocation is 32bit and main/DSO are several GB
> apart. For x86_64, we can warn it when creating such a shared
> library and refuse to link if it is referenced by main.
> 

This is my proposal.


H.J.
-----
There is a problem on ia32 and x86_64, where copy relocation is
used to allow main executable to access data variables in DSO.
Normally, linker will create a copy relocation when main references a
data variable in DSO. At the runtime, dynamic linker will create a copy
of the data variable from DSO to the address space of main. It will
arrange both DSO and main to access the copy in main instead of the
original one in DSO. When a data variable in DSO is marked protected,
DSO will always use the original one it has and main will use the copy.
Now, main and DSO will see 2 different ones even though the one in main
is just a copy of the original one.

I am proposing

1. For ia32, when creating a shared library with a protected data
variable, we warn that the resulting DSO will lead to main executable
to be compiled with PIC or be generated with writable text section when
the data variable is accessed. Linker will issue a warning when a main
executable is made with writable text section because of it.
2. For x86_64, when creating a shared library a protected data
variable, we warn that the resulting DSO will lead to main executable
to be compiled with PIC when the data variable is referenced. Linker
will issue an error when a main executable references a protected data
symbol with R_X86_64_PC32 since main and DSO may be more than 2GB
apart.