From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66307 invoked by alias); 30 Aug 2016 08:10:44 -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 66294 invoked by uid 89); 30 Aug 2016 08:10:44 -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,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=bank, secure X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Aug 2016 08:10:33 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7C12A349; Tue, 30 Aug 2016 01:10:32 -0700 (PDT) Received: from [10.2.206.52] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0C1553F32C; Tue, 30 Aug 2016 01:10:31 -0700 (PDT) Subject: Re: [RFC PATCH, binutils, ARM 11/11, ping] Add support for stable secure gateway veneers addresses To: Christophe Lyon References: <005601d13d58$522afb60$f680f220$@foss.arm.com> <1796369.8BmbsroDJA@e108577-lin> <577E5070.3020606@arm.com> <4163700.8nzTNaTl0I@e108577-lin> <378f9855-1f2f-abcc-6030-b077e9b1932e@foss.arm.com> <5b0cd645-7628-705f-3c86-7388513c0708@arm.com> <5f9e12c3-b5b5-1e7d-e319-018a270690e9@foss.arm.com> <0051e9d5-09e6-8bb1-fc15-40693a82fc6f@arm.com> <778fe071-0d3d-aa68-0923-aff851b7d656@foss.arm.com> <210bfecf-d453-62f6-7657-ea22ed3bc006@foss.arm.com> Cc: binutils@sourceware.org From: Thomas Preudhomme Message-ID: Date: Tue, 30 Aug 2016 08:10: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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00317.txt.bz2 Hi Christophe, On 29/08/16 15:56, Christophe Lyon wrote: > On 26 August 2016 at 16:18, Thomas Preudhomme > wrote: >> On 26/08/16 13:36, Thomas Preudhomme wrote: >>> >>> Hi Christophe, >>> >>> On 26/08/16 12:55, Christophe Lyon wrote: >>>> >>>> >>>> I've noticed that the new tests fail on armeb. I didn't look at the >>>> detailed logs yet, but I guess you can a look? >>>> >>>> ./ld/ld.sum:FAIL: Input secure gateway import library >>>> ./ld/ld.sum:FAIL: Input secure gateway import library: no output import >>>> library >>>> ./ld/ld.sum:FAIL: Input secure gateway import library: earlier stub >>>> section base >>>> ./ld/ld.sum:FAIL: Input secure gateway import library: later stub section >>>> base >>>> ./ld/ld.sum:FAIL: Input secure gateway import library: veneer comeback >>>> ./ld/ld.sum:FAIL: Input secure gateway import library: entry function >>>> change >>> >>> >>> I can reproduce indeed. I'll have a look, thanks for the notice. Note that >>> Monday is a bank holidays here so might only answer after that if I'm too >>> slow >>> to find the root cause. >> >> >> Doh, the code checks for a SG instruction by comparing the 4 bytes in the >> code against its litteral value. The problem of course is that the read puts >> the 4 bytes of the instruction in memory order but these will then be >> interpreted according to the endianness. >> >> The fix should be easy. >> > > Indeed, thanks to your analysis it was quick enough. > > Here is a patch, maybe there is a simpler way? diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c index 9ff418a..5c04b9b 100644 --- a/bfd/elf32-arm.c +++ b/bfd/elf32-arm.c @@ -5791,11 +5791,19 @@ cmse_entry_fct_p (struct elf32_arm_link_hash_entry *hash) section = hash->root.root.u.def.section; abfd = section->owner; offset = hash->root.root.u.def.value - section->vma; - if (!bfd_get_section_contents (abfd, section, &first_insn, offset, - sizeof (first_insn))) - return FALSE; /* Start by SG instruction. */ + bfd_byte * contents; + /* Get cached copy if it exists. */ + if (elf_section_data (section)->this_hdr.contents != NULL) + contents = elf_section_data (section)->this_hdr.contents; + else + { + /* Go get them off disk. */ + if (! bfd_malloc_and_get_section (abfd, section, &contents)) + return FALSE; + } + first_insn = bfd_get_32 (abfd, contents + offset); return first_insn == 0xe97fe97f; } I have a similar patch but I'm still using bfd_get_section_contents with a 4byte buffer named contents. It avoids reading the entire section to just analyze 4 bytes. I did it on Friday so wanted to test it a bit more today. Best regards, Thomas