From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26823 invoked by alias); 20 Jul 2007 12:50:58 -0000 Received: (qmail 26813 invoked by uid 22791); 20 Jul 2007 12:50:57 -0000 X-Spam-Check-By: sourceware.org Received: from alnrmhc12.comcast.net (HELO alnrmhc12.comcast.net) (206.18.177.52) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Jul 2007 12:50:54 +0000 Received: from lucon.org ([24.6.230.138]) by comcast.net (alnrmhc12) with ESMTP id <20070720125052b1200ddvk5e>; Fri, 20 Jul 2007 12:50:53 +0000 Received: by lucon.org (Postfix, from userid 500) id A882CF824D; Fri, 20 Jul 2007 05:50:52 -0700 (PDT) Date: Fri, 20 Jul 2007 13:07:00 -0000 From: "H.J. Lu" To: Ian Lance Taylor , binutils@sourceware.org, richard@codesourcery.com Subject: Re: PATCH: Check symbol type for symbol alias Message-ID: <20070720125052.GA1973@lucon.org> References: <87k5t0ff65.fsf@firetop.home> <20070716203505.GA15885@lucon.org> <20070717131132.GA17994@lucon.org> <20070718134451.GA23380@lucon.org> <87644hzost.fsf@firetop.home> <20070718191022.GA24694@lucon.org> <20070719173234.GA29794@lucon.org> <87wswvv3p1.fsf@firetop.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wswvv3p1.fsf@firetop.home> User-Agent: Mutt/1.5.14 (2007-02-12) Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00339.txt.bz2 On Fri, Jul 20, 2007 at 10:12:42AM +0100, Richard Sandiford wrote: > "H.J. Lu" writes: > > Here is a patch to add a testcase and check symbol type for symbol > > alias. > > In case anyone's in any doubt, this really doesn't fix my original > problem. Although the strong symbol in the test's shared library was > defined by the linker script, that was mostly for test convenience. > We can still have a situation in which an object symbol "bar" in a > shared library is overridden by an assignment "PROVIDE (bar = .);" in > the linker script of an object being linked against the shared library. > (And as I said in the covering note, we do handle that situation > correctly; we use relocations against the original weak symbol instead.) > I can adjust the testcase in the obvious way if this patch goes in. The problem is linker creates a wrong symbol alias for a dynamic object. We don't have a reliable way to tell if a symbol is an aliase in a shared library. It can lead to many problems. Can we use STT_SECTION for linker created symbols? Gabi says STT_SECTION The symbol is associated with a section. Symbol table entries of this type exist primarily for relocation and normally have STB_LOCAL binding. It doesn't forbid STB_GLOBAL binding. At least, we won't make a weak symbol an alias of linker created symbols. H.J.