From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92598 invoked by alias); 19 Aug 2016 07:53:25 -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 92588 invoked by uid 89); 19 Aug 2016 07:53:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=output_bfd, UD:root.type, sk:bfd_lin, root.type X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Aug 2016 07:53:14 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 10C2321A3; Fri, 19 Aug 2016 07:53:13 +0000 (UTC) Received: from [10.36.5.216] (vpn1-5-216.ams2.redhat.com [10.36.5.216]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7J7rA6t017466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2016 03:53:12 -0400 Subject: Re: [PATCH 3/5] Several fixes related to ARC PIE support. To: Cupertino Miranda , binutils@sourceware.org References: <20160816155116.23937-1-cmiranda@synopsys.com> <20160816155116.23937-4-cmiranda@synopsys.com> Cc: Francois.Bedard@synopsys.com, Claudiu.Zissulescu@synopsys.com From: Nick Clifton Message-ID: <490c7748-916e-4b94-2aa7-e4ea13d68a8b@redhat.com> Date: Fri, 19 Aug 2016 07:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160816155116.23937-4-cmiranda@synopsys.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00139.txt.bz2 Hi Cupertino, > bfd/ChangeLog: > Cupertino Miranda > > elf-bfd.h: Added ARC_ELF_DATA to enum elf_target_id. > elf32-arc.c (struct elf_arc_link_hash_entry): Added. > (struct elf_arc_link_hash_table): Likewise. > (elf_arc_link_hash_newfunc): Likewise. > (elf_arc_link_hash_table_free): Likewise. > (arc_elf_link_hash_table_create): Likewise. > (elf_arc_relocate_section): Fixed conditions related to dynamic > (elf_arc_check_relocs): Likewise. > (arc_elf_create_dynamic_sections): Added > (elf_arc_adjust_dynamic_symbol): Changed access to .rela.bss to be done > through the hash table. One minor point and one question: > +/* Create an X86-64 ELF linker hash table. */ Cut and paste typo - I assume that you meant 'Create an ARC ELF linker hash table'. > @@ -2020,17 +2148,21 @@ elf_arc_finish_dynamic_symbol (bfd * output_bfd, > > if (h->needs_copy) > { > + struct elf_arc_link_hash_table *arc_htab = elf_arc_hash_table (info); > + > + if (h->dynindx == -1 > + || (h->root.type != bfd_link_hash_defined > + && h->root.type != bfd_link_hash_defweak) > + || arc_htab->srelbss == NULL) > + abort (); I am not sure if an abort is the correct function to call here. Abort should only be called if there is an internal error in the library. If it is possible for bad user input to trigger the situation then an error message should be generated instead. I have not followed through all the logic, so maybe the conditions being tested should all be satisfied by earlier parts in the linking process, (in which case a BFD_ASSERT would be better than a direct call to abort), but it seems to me that it might be possible for a dynamic symbol to become undefined somehow, and in that case an error message would be more appropriate. Cheers Nick