From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5355 invoked by alias); 9 Nov 2004 16:29:41 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 5324 invoked from network); 9 Nov 2004 16:29:34 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org with SMTP; 9 Nov 2004 16:29:34 -0000 Received: from lucon.org ([24.6.212.230]) by comcast.net (sccrmhc13) with ESMTP id <200411091629330160011kb9e>; Tue, 9 Nov 2004 16:29:33 +0000 Received: by lucon.org (Postfix, from userid 1000) id CE65964060; Tue, 9 Nov 2004 08:29:32 -0800 (PST) Date: Tue, 09 Nov 2004 16:29:00 -0000 From: "H. J. Lu" To: "Aaron W. LaFramboise" Cc: binutils@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: PATCH: PR 528: .set is broken for weak symbols Message-ID: <20041109162932.GA1112@lucon.org> References: <20041108235940.GA18970@lucon.org> <20041109003025.GA19446@lucon.org> <41906859.60608@aaronwl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41906859.60608@aaronwl.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-11/txt/msg00165.txt.bz2 On Tue, Nov 09, 2004 at 12:48:57AM -0600, Aaron W. LaFramboise wrote: > H. J. Lu wrote: > > > On Mon, Nov 08, 2004 at 03:59:40PM -0800, H. J. Lu wrote: > > > >>This patch > >> > >>http://sources.redhat.com/ml/binutils/2004-11/msg00098.html > >> > >>breaks .set, which should only copy the value, not other flags. See > >> > >>http://sources.redhat.com/bugzilla/show_bug.cgi?id=528 > > Sorry for the breakage. I don't understand exactly whats going wrong > here, though. See below. > > .set doesn't just copy value, though; its used to equate symbols. For > example, __attribute__((weak, alias ("..."))) uses .set for most (all?) > platforms. > > I don't understand why it is correct for your testcase foo.o to not > generate a relocation; if weak symbol bar is overriden in another > object, the operand to "jmp" will not be overriden, despite having been > equated to the weak symbol being overriden. > > This would mean that local symbols equated to the weak symbol would > resolve to a different function than non-local symbols equated to the > same weak symbol, which seems very wrong to me. In addition, it means > that a weak function might actually be used, despite being overridden by > a strong function. This is also suprising, as one would expect that a > weak function overriden by a strong one would never be used. > .set should just copy value and type. Be default, the new symbol is always local. BTW, .weak foo implies .global foo > > 1. Should .set change the behavior on weak symbols on any platforms? > > Does gcc expect that? > > I think GCC does expect that .set will do more than just copy the value > in the case of weak symbols. I don't think so. Otherwise, there is no need to use ".set". It can use the original symbol instead. > > > 2. The ChangeLog entry has > > > > 2004-11-08 Aaron W. LaFramboise > > > > * symbols.c (any_external_name): Define. > > (resolve_symbol_value): Do not convert weak symbols. > > ^^^^^^^ > > Is this a typo? From the code, it seems that weak symbols are > > converted. > > Yes, you're right; this is a typo. > > > * symbols.c (resolve_symbol_value): Convert weak symbols only > > for Windows PECOFF. > > This conversion is necessary for the same reason conversion is necessary > with undefined symbols: since the equated-to symbol is weak, the equated > symbol's value will be incorrect if the equated-to weak symbol is > overriden. In other words, symbol A is equated to weak symbol B, and a > relocation against A is not converted to be against B, if B is > overriden, the relocation couldn't possibly come out right after fixup. > > Why is this not the case with ELF? > > > (symbol_equated_reloc_p): Don't equate weaks when relocating > > only for Windows PECOFF. > > This is necessary for similar reasons as the above, but opposite. Since > a weak symbol may later be overridden, and thus no longer equated, it is > not safe to assume that it is equated. In other words, weak symbol C is > equated to symbol D. If the reloc code assumes that C is equated to D, > then that relocation is against D. If C is later overridden, the > relocation will be incorrect, as the fixup will be against D, which > won't be the same as C. > > Why is this not the case with ELF? The key is ".set" is not used to equate symbols. It is used to set a symbol with the same value and type. If the symbol doesn't exist before, the new symbol will be local. H.J.