From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20563 invoked by alias); 4 Aug 2006 01:30:42 -0000 Received: (qmail 20554 invoked by uid 22791); 4 Aug 2006 01:30:41 -0000 X-Spam-Check-By: sourceware.org Received: from omta03sl.mx.bigpond.com (HELO omta03sl.mx.bigpond.com) (144.140.92.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 04 Aug 2006 01:30:40 +0000 Received: from grove.modra.org ([60.226.255.233]) by omta03sl.mx.bigpond.com with ESMTP id <20060804013032.HBRP2500.omta03sl.mx.bigpond.com@grove.modra.org>; Fri, 4 Aug 2006 01:30:32 +0000 Received: by bubble.grove.modra.org (Postfix, from userid 500) id 699B31D9C8B; Fri, 4 Aug 2006 11:00:32 +0930 (CST) Date: Fri, 04 Aug 2006 01:30:00 -0000 From: Alan Modra To: Steven Munroe Cc: Richard Sandiford , binutils@sourceware.org Subject: Re: Link problems with section anchors Message-ID: <20060804013032.GB23605@bubble.grove.modra.org> Mail-Followup-To: Steven Munroe , Richard Sandiford , binutils@sourceware.org References: <44D2755E.9020600@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D2755E.9020600@us.ibm.com> User-Agent: Mutt/1.4i X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00037.txt.bz2 On Thu, Aug 03, 2006 at 05:14:54PM -0500, Steven Munroe wrote: > `.LANCHOR0' referenced in section `.text' of libc_pic.a(strtoul_l.os): > defined in discarded section `.gnu.linkonce.r.__strtol_ul_max_tab' of > libc_pic.a(strtoul_l.os) > `.LANCHOR1' referenced in section `.text' of libc_pic.a(strtoul_l.os): > defined in discarded section `.gnu.linkonce.r.__strtol_ul_rem_tab' of > libc_pic.a(strtoul_l.os) > ... > > This is related to -fsection-anchors because rebuilding with > -fno-section-anchors makes the problem go away. Taking a look at -fno-section-anchors strtoul_l.os 000000fe 00000f0e R_PPC_GOT16 00000000 __strtol_ul_max_tab + 0 00000102 0000100e R_PPC_GOT16 00000000 __strtol_ul_rem_tab + 0 15: 00000000 140 OBJECT GLOBAL HIDDEN 5 __strtol_ul_max_tab 16: 00000000 35 OBJECT GLOBAL HIDDEN 6 __strtol_ul_rem_tab vs -fsection-anchors strtoul_l_os 000000fe 0000060e R_PPC_GOT16 00000000 .LANCHOR0 + 0 00000102 0000080e R_PPC_GOT16 00000000 .LANCHOR1 + 0 6: 00000000 0 NOTYPE LOCAL DEFAULT 5 .LANCHOR0 8: 00000000 0 NOTYPE LOCAL DEFAULT 6 .LANCHOR1 Note the difference in local vs. global symbol used on the GOT reloc. GOT relocs work by creating one entry in .got per symbol, so for example if there are a dozen GOT relocs referencing __strtol_ul_max_tab you get just one entry in .got. Global symbols merge. There can only be one strong definition of a global symbol, and all references resolve to that single definition. However, .LANCHOR0 is local, so is a different symbol to .LANCHOR0 in some other file. Thus the GOT reloc referencing .LANCHOR0 in this file creates a separate .got entry to a GOT reloc in another file referencing .LANCHOR0. I'd say this is a gcc bug. (The GOT reloc can't really use section anchors anyway because sym+off@got has rather useless semantics, so why can't gcc use the original symbol?) ld can't treat the local symbols in linkonce sections as if they were global because .LANCHOR0 in .gnu.linkonce.r.__strtol_ul_max_tab must be different from .LANCHOR0 in .gnu.linkonce.r.some_other_name. Hmm, I suppose ld could create a new global name that incorporated the section name, and do the same for section groups, but twiddling relocs to use a different symbol is non-trivial. -- Alan Modra IBM OzLabs - Linux Technology Centre