From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5959 invoked by alias); 16 Nov 2013 07:50:15 -0000 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 Received: (qmail 5948 invoked by uid 89); 16 Nov 2013 07:50:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pb0-f47.google.com Received: from Unknown (HELO mail-pb0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 16 Nov 2013 07:50:13 +0000 Received: by mail-pb0-f47.google.com with SMTP id rr4so3106135pbb.20 for ; Fri, 15 Nov 2013 23:50:05 -0800 (PST) X-Received: by 10.69.18.234 with SMTP id gp10mr3005303pbd.105.1384588205094; Fri, 15 Nov 2013 23:50:05 -0800 (PST) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPSA id 7sm10467772paf.22.2013.11.15.23.50.02 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 23:50:04 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 58EF1EA006D; Sat, 16 Nov 2013 18:19:50 +1030 (CST) Date: Sat, 16 Nov 2013 07:50:00 -0000 From: Alan Modra To: Roland McGrath Cc: "Maciej W. Rozycki" , "binutils@sourceware.org" Subject: Re: [PATCH] Fix references to __ehdr_start when it cannot be defined Message-ID: <20131116074950.GG22514@bubble.grove.modra.org> Mail-Followup-To: Roland McGrath , "Maciej W. Rozycki" , "binutils@sourceware.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00158.txt.bz2 On Mon, Nov 11, 2013 at 03:06:54PM -0800, Roland McGrath wrote: > I'm not really sure that's possible. It's only knowable when deciding > the file layout, which is after the address layout has been done. If [snip] It's quite possible to define a symbol then come back later and fix the value, but this is all by the way. [snip] > The problem (vs the original __ehdr_start implementation) seems to arise this: > > /* Since we're defining the symbol, don't let it seem to have not > been defined. record_dynamic_symbol and size_dynamic_sections > may depend on this. */ > h->root.type = bfd_link_hash_new; > if (h->root.u.undef.next != NULL || htab->root.undefs_tail == &h->root) > bfd_link_repair_undef_list (&htab->root); > > in bfd_elf_record_link_assignment. > > In the case of __ehdr_start, we're not defining the symbol and it should Right, and bfd_elf_record_link_assignment was designed to handle defining symbols.. I owe you and Maciej an apology, since it was my suggestion to use bfd_elf_record_link_assignment here. Let's go back to Maciej's original submission, modified somewhat. Ideally, we would have some function to prevent symbols from being made dynamic, which is what elf32.em:before_allocation is trying to do for "__ehdr_start". See also elf64-ppc.c:ppc64_elf_func_desc_adjust where the same thing is done for ".TOC." without knowing the proper value. Maciej, this gets FAIL: MIPS magic __ehdr_start symbol test 2 (o32) because the linker script defines __ehdr_start and so the symbol is not made hidden and forced_local. Should we update the testcase, or do you think __ehdr_start should always be hidden? The latter can be done by simply removing the h->root.type tests. * emultempl/elf32.em (before_allocation): Don't use bfd_link_record_link_assignment to hide __ehdr_start. diff --git a/ld/emultempl/elf32.em b/ld/emultempl/elf32.em index 682f5e5..5f776a0 100644 --- a/ld/emultempl/elf32.em +++ b/ld/emultempl/elf32.em @@ -1487,10 +1487,26 @@ gld${EMULATION_NAME}_before_allocation (void) /* Make __ehdr_start hidden if it has been referenced, to prevent the symbol from being dynamic. */ - if (!bfd_elf_record_link_assignment (link_info.output_bfd, &link_info, - "__ehdr_start", TRUE, TRUE)) - einfo ("%P%F: failed to record assignment to %s: %E\n", - "__ehdr_start"); + if (!link_info.relocatable) + { + struct elf_link_hash_entry *h; + + h = elf_link_hash_lookup (elf_hash_table (&link_info), "__ehdr_start", + FALSE, FALSE, TRUE); + + /* Only adjust the export class if the symbol was referenced + and not defined, otherwise leave it alone. */ + if (h != NULL + && (h->root.type == bfd_link_hash_new + || h->root.type == bfd_link_hash_undefined + || h->root.type == bfd_link_hash_undefweak + || h->root.type == bfd_link_hash_common)) + { + _bfd_elf_link_hash_hide_symbol (&link_info, h, TRUE); + if (ELF_ST_VISIBILITY (h->other) != STV_INTERNAL) + h->other = (h->other & ~ELF_ST_VISIBILITY (-1)) | STV_HIDDEN; + } + } /* If we are going to make any variable assignments, we need to let the ELF backend know about them in case the variables are -- Alan Modra Australia Development Lab, IBM