Re: RFC: Disallow protected data symbol with copy relocation?

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

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.


H.J.