From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B290521A16ECB for ; Sun, 28 May 2017 05:07:19 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id p24so29381866ioi.0 for ; Sun, 28 May 2017 05:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P1DrMBUR9Zai3D/pP7yeHS7UUl4i9Fj6ydlPK1BDkFs=; b=SKOL7PUnjdPcYRsuBvGYwZ9UwcbBJPuGgr4HmZps0KGoMerbjChaFWHMneKmW/RLSw NsMgA6a+JHujGq0yg9exFHSGofZDVmVV0IczjWU8m+Yocrf7Z7Q3sqL6IObbMpUcK4fr n+v5tbP9pFvVFGHv+62XYgKmE/n7Kh7AZVn0k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P1DrMBUR9Zai3D/pP7yeHS7UUl4i9Fj6ydlPK1BDkFs=; b=jfn9yiHKyWnDp8GNbNM5/11rKRxTwd/2k1JlEXX/Jeu1DIyeX4aCS2krzMp49XgQ9z aFIqacNNZ5pIj3Dx5STXiR9ah0e5U1IHdtZl0frjWSQ5OUxeejVb95HE7tSXVdvyeJKF NjxY8vx+x+k3NHO9VAYQ8YPeQJiqrSbgRDHuvRsmwDwZgoagouaPIDOrGViuRQqg7B69 yaLgRgIgRdzoqUAa3Nm8ByvUkgqkTBI1sE4p1v6rmhQp8qDtZqDwCt5JV/Ch/VM9H5Q9 VdnIdjMO1q+gflZKpgTqrMwuj4qSpO6iNaHYG8SaAOiknHCrFqlUYNaTTqTarp3d51nx OLjg== X-Gm-Message-State: AODbwcAp/qwbNn9hvut2eRXs28G9VGsZlDnH5WjPm+TlzZvrpcpkStO4 oW9YthDUZ/zGfKKXuAf4miwtblEv+tjw X-Received: by 10.107.130.166 with SMTP id m38mr10056208ioi.87.1495973295674; Sun, 28 May 2017 05:08:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.24 with HTTP; Sun, 28 May 2017 05:08:15 -0700 (PDT) In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14D740305@shsmsx102.ccr.corp.intel.com> References: <20170519104740.16044-1-ard.biesheuvel@linaro.org> <4A89E2EF3DFEDB4C8BFDE51014F606A14D7326EA@shsmsx102.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D740305@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Sun, 28 May 2017 12:08:15 +0000 Message-ID: To: "Gao, Liming" Cc: "edk2-devel@lists.01.org" , "leif.lindholm@linaro.org" , "Zhu, Yonghong" Subject: Re: [PATCH] BaseTools/Scripts: discard .gnu.hash section in GCC builds X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 12:07:20 -0000 Content-Type: text/plain; charset="UTF-8" On 27 May 2017 at 09:05, Gao, Liming wrote: > Ard: > I just run BaseTools\Scripts\PatchCheck.py to check the latest patches. It reports one issue in this patch. Could you fix it? > Pushed as f4d3ba87bb8f -- Ard. > The commit message format passed all checks. > Code format is not valid: > * Line ending ('\n') is not CRLF > File: BaseTools/Scripts/GccBase.lds > Line: *(.hash .gnu.hash) > > Thanks > Liming >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >> Sent: Wednesday, May 24, 2017 9:13 PM >> To: Gao, Liming >> Cc: edk2-devel@lists.01.org; leif.lindholm@linaro.org; Zhu, Yonghong >> Subject: Re: [PATCH] BaseTools/Scripts: discard .gnu.hash section in GCC builds >> >> On 21 May 2017 at 21:05, Gao, Liming wrote: >> > Reviewed-by: Liming Gao >> > >> >> Thanks. Pushed as 00b00cc57bfe0fca54c904d4dd44a263e243c88b >> >> >>-----Original Message----- >> >>From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >> >>Sent: Friday, May 19, 2017 6:48 PM >> >>To: edk2-devel@lists.01.org >> >>Cc: leif.lindholm@linaro.org; Zhu, Yonghong ; Gao, >> >>Liming ; Ard Biesheuvel >> >>Subject: [PATCH] BaseTools/Scripts: discard .gnu.hash section in GCC builds >> >> >> >>Some builds of GCC/binutils will default to using the GNU flavor of >> >>the symbol hash table, and will emit it into a section called .gnu.hash >> >>rather than .hash. We have no use for its contents, and GenFw ignores >> >>it anyway, so it shouldn't really matter what we do with it. >> >> >> >>However, due to a workaround for AARCH64 we have in GenFw to deal with >> >>older GCCs that corrupt section-based relocations when merging sections >> >>during the final link, we need the ELF and PE/COFF views of the binary >> >>to be identical. Since we don't place the .gnu.hash section explicitly, >> >>it may end up at the beginning of the ELF binary, causing other sections >> >>to be shifted in the ELF view but not in the PE/COFF view. >> >> >> >>So let's add .gnu.hash to the GCC linker script. We don't care about its >> >>contents so add it to the /DISCARD/ section. >> >> >> >>Contributed-under: TianoCore Contribution Agreement 1.0 >> >>Signed-off-by: Ard Biesheuvel >> >>--- >> >> BaseTools/Scripts/GccBase.lds | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >>diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds >> >>index 41e5c0b4a769..a43e0072f2b4 100644 >> >>--- a/BaseTools/Scripts/GccBase.lds >> >>+++ b/BaseTools/Scripts/GccBase.lds >> >>@@ -78,7 +78,7 @@ SECTIONS { >> >> *(.dynsym) >> >> *(.dynstr) >> >> *(.dynamic) >> >>- *(.hash) >> >>+ *(.hash .gnu.hash) >> >> *(.comment) >> >> *(COMMON) >> >> } >> >>-- >> >>2.9.3 >> >