From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-37336-listarch-binutils=sources.redhat.com@sources.redhat.com>
Received: (qmail 17971 invoked by alias); 21 Jan 2005 05:52:37 -0000
Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:binutils-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/binutils/>
List-Post: <mailto:binutils@sources.redhat.com>
List-Help: <mailto:binutils-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: binutils-owner@sources.redhat.com
Received: (qmail 17925 invoked from network); 21 Jan 2005 05:52:33 -0000
Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39)
  by sourceware.org with SMTP; 21 Jan 2005 05:52:33 -0000
Received: from lucon.org ([24.6.212.230]) by comcast.net (rwcrmhc13) with ESMTP
          id <2005012105523301500copobe>; Fri, 21 Jan 2005 05:52:33 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id B93C9640EF; Thu, 20 Jan 2005 21:52:32 -0800 (PST)
Date: Fri, 21 Jan 2005 05:52:00 -0000
From: "H. J. Lu" <hjl@lucon.org>
To: binutils@sources.redhat.com, gcc@gcc.gnu.org,
	hongjiu.lu@intel.com
Subject: Re: RFC: Disallow protected data symbol with copy relocation?
Message-ID: <20050121055232.GA27333@lucon.org>
References: <20050121045753.GA26471@lucon.org> <m3ekgfpdze.fsf@gossamer.airs.com> <20050121051817.GA26819@lucon.org> <m3acr3pc5p.fsf@gossamer.airs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m3acr3pc5p.fsf@gossamer.airs.com>
User-Agent: Mutt/1.4.1i
X-SW-Source: 2005-01/txt/msg00331.txt.bz2

On Fri, Jan 21, 2005 at 12:46:26AM -0500, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > > Why would the linker ever generate a copy relocation for a protected
> > > symbol?  I don't see how that makes sense.
> > > 
> > 
> > For some psABIs, copy relocation is the normal way for main to access
> > data symbol on DSO.
> > ...
> 
> Yes, I know.  But clearly a copy relocation can not work.  We should
> treat this case as though -z nocopyreloc was used for that specific
> symbol.
> 
> Maybe that is what you meant by "reject protected data symbol with
> copy relocation."  I am saying that the answer is not to reject the
> symbol, it is to not generate the copy relocation.

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.

> 
> There may be specific targets and/or cases where -z nocopyreloc does
> not work, for some hideous reason.  Those specific targets and/or
> cases should generate a specific error.  But this is not a general
> problem.

I don't think -z nocopyreloc works on x86_64.


H.J.