From patchwork Mon Nov 28 12:45:28 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 84392 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp1116240qgi; Mon, 28 Nov 2016 04:46:02 -0800 (PST) X-Received: by 10.99.142.201 with SMTP id k192mr38802797pge.174.1480337162382; Mon, 28 Nov 2016 04:46:02 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id k1si18537830pld.26.2016.11.28.04.46.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 04:46:02 -0800 (PST) Received-SPF: pass (google.com: domain of binutils-return-94623-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org; spf=pass (google.com: domain of binutils-return-94623-patch=linaro.org@sourceware.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=binutils-return-94623-patch=linaro.org@sourceware.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type; q=dns; s=default; b=fgyw 1pl6B1sPe1iQUyg4lmXSDTG2d7hYtsKmiBJnj6hZOg9Qxm+36fcYQea2rwmZrMvT MwVMpYDx4gnNC55t4JBE8ALjfAr5e9H+t3mgv6d5a5cUlont3WJ8rVpCaJq1VJ/D s1xLo3hiu8Gf2HClg3K9CU3W09GpbAzTB+8f//I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type; s=default; bh=gE8L9BobVK Ond/ZtWywFOQ8FWpo=; b=I7+JR4ETBNefwHp3vylSNfjb6muVFpHacwnb2RRyAn I1wQrAy2De+wtiJN4+tLKpBxHZl5+6nGUpOEMlzQkpHym8iEFjcn6uEezZBs5YiH RkbUNvfiJ8O2OWdqlL278sFhDabr0psA45B0FgUBeJaVcji3wArWTm4jHHF0IkOZ g= Received: (qmail 126412 invoked by alias); 28 Nov 2016 12:45:42 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Delivered-To: mailing list binutils@sourceware.org Received: (qmail 126374 invoked by uid 89); 28 Nov 2016 12:45:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=officially, 56, sk:_bfd_el, sk:elf_int 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; Mon, 28 Nov 2016 12:45:31 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 60DA78FCF6; Mon, 28 Nov 2016 12:45:30 +0000 (UTC) Received: from [10.36.7.146] (vpn1-7-146.ams2.redhat.com [10.36.7.146]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uASCjSOe000710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2016 07:45:29 -0500 Subject: Re: Fix for PR ld/20815 doesn't allow to build a working kernel To: Matthias Klose References: <9a0a9f3a-ecec-6009-ca59-409e1466a52d@debian.org> Cc: binutils From: Nick Clifton Message-ID: Date: Mon, 28 Nov 2016 12:45:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9a0a9f3a-ecec-6009-ca59-409e1466a52d@debian.org> X-IsSubscribed: yes Hi Matthias, > https://bugs.debian.org/845690 reports that trunk 20161124 doesn't allow to > build a working kernel on at least x86_64. I verified that reverting the fix > for PR ld/20815 allows to build a working kernel again. I think that Alan is probably right - it is likely to be the code that sorts the program headers into ascending order of p_vaddr that is causing the problem. (It would be nice if the kernel could actually tell us what is wrong however). Rather than revert the whole patch, since doing so does allow the linker to silently create broken binaries, would it be possible for you to try out the attached patch instead ? (Actually there are two attachments: pr20815.elf.c.patch is the change that you need to revert the sorting of PT_LOAD segments, and which should allow you to test to see if it is sufficient to produce working kernels. pr20815.rest.patch is a fix to the linker testsuite to adjust the tests that would fail with the elf.c patch applied, and a patch to the readelf program to stop it from complaining about binaries with out of order PT_LOAD segments). Cheers Nick diff --git a/binutils/readelf.c b/binutils/readelf.c index 347b6b9..854e99f 100644 --- a/binutils/readelf.c +++ b/binutils/readelf.c @@ -4909,9 +4909,13 @@ process_program_headers (FILE * file) switch (segment->p_type) { case PT_LOAD: +#if 0 /* Do not warn about out of order PT_LOAD segments. Although officially + required by the ELF standard, several programs, including the Linux + kernel, make use of non-ordered segments. */ if (previous_load && previous_load->p_vaddr > segment->p_vaddr) error (_("LOAD segments must be sorted in order of increasing VirtAddr\n")); +#endif if (segment->p_memsz < segment->p_filesz) error (_("the segment's file size is larger than its memory size\n")); previous_load = segment; diff --git a/ld/testsuite/ld-elf/loadaddr1.d b/ld/testsuite/ld-elf/loadaddr1.d index 0aa372c..0fd96a7 100644 --- a/ld/testsuite/ld-elf/loadaddr1.d +++ b/ld/testsuite/ld-elf/loadaddr1.d @@ -5,6 +5,6 @@ #... LOAD +0x000000 0xf*80000000 0xf*80000000 0x100050 0x100050 RWE 0x200000 - LOAD +0x302000 0xf*80102000 0xf*80102000 0x0*10 0x0*10 RW 0x200000 LOAD +0x200000 0xf*ff600000 0xf*80101000 0x0*10 0x0*10 R E 0x200000 + LOAD +0x302000 0xf*80102000 0xf*80102000 0x0*10 0x0*10 RW 0x200000 #pass diff --git a/ld/testsuite/ld-powerpc/vle-multiseg-5.d b/ld/testsuite/ld-powerpc/vle-multiseg-5.d index 97de87d..c223876 100644 --- a/ld/testsuite/ld-powerpc/vle-multiseg-5.d +++ b/ld/testsuite/ld-powerpc/vle-multiseg-5.d @@ -6,11 +6,11 @@ There are 3 program headers, starting at offset [0-9]+ Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD ( +0x[0-9a-f]+){5} R E 0x[0-9a-f]+ - LOAD ( +0x[0-9a-f]+){5} R E 0x[0-9a-f]+ LOAD ( +0x[0-9a-f]+){5} RW 0x[0-9a-f]+ + LOAD ( +0x[0-9a-f]+){5} R E 0x[0-9a-f]+ Section to Segment mapping: Segment Sections... 00 .text_vle .text_iv - 01 .iv_handlers - 02 .data + 01 .data + 02 .iv_handlers diff --git a/ld/testsuite/ld-scripts/phdrs3a.d b/ld/testsuite/ld-scripts/phdrs3a.d index d96bd13..80bde71 100644 --- a/ld/testsuite/ld-scripts/phdrs3a.d +++ b/ld/testsuite/ld-scripts/phdrs3a.d @@ -4,6 +4,6 @@ #readelf: -l --wide #... -[ \t]+LOAD[ x0-9a-f]+ E [ x0-9a-f]+ [ \t]+LOAD[ x0-9a-f]+ R [ x0-9a-f]+ +[ \t]+LOAD[ x0-9a-f]+ E [ x0-9a-f]+ #pass