From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 BDCEE1A1E20 for ; Thu, 28 Jul 2016 23:40:41 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m101so120545305ioi.2 for ; Thu, 28 Jul 2016 23:40:41 -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:content-transfer-encoding; bh=Y+4qZh+sL8Tcy2IWi9I0ba7DavQL1jjttdzupoIQ7F4=; b=fc7NpFVBO/DoWS09P63UuNBtbwjo8bCquDfwoni3jQq13lqkOFX3SY1hFzmfMuBXux +ZCkNC2Hx4juvS3rkL4H/sRS224hyA7YbZBq7GWTpd3aOe3FzL6p2ZlzngWxQ1stPjcW vMiPe/cPkQvzrqfgtOfnzRIA5iKOSyLbgCUnY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Y+4qZh+sL8Tcy2IWi9I0ba7DavQL1jjttdzupoIQ7F4=; b=ku8FWVZXVswmCouaBK42tydhWNuRz7cB0XK+3uI1p7JvfoVr3jgp1ZD5wbpAzk7Pwo 8VSSZoPo5dBs8kkxI8ZSFNguhjkf+1g4rbMH1u6s49aIXsYryK9GHQarXElQoH+QPhlY TuY16Om+5UDCu1/m/O0e8jnj0Si5PJelwSq6cQsYfDO4Q8XqucA5ktNi1bL3Cac+/3c/ 8gGKV0VCL+Dy0nLcHfJqeVuQDrvcWfXgZi23OHUtGEzgx2ohoMafm/uss7CJDGV84SR7 BxrsY5SfxuXHRh1qTFYtI1X1quN62DGZU9Fd0/jkmVCft7a6BjSe8QWGuKIU1aDChHlI +4YA== X-Gm-Message-State: AEkooutnRqkGtQ+A7MsmgjmIjPlnWm871nuO6BVZWWw0Ycx5l34drayqbxsc8baa3tc/WR6Vc7ZgaZJS6m9OZmCU X-Received: by 10.107.41.67 with SMTP id p64mr40653167iop.130.1469774441098; Thu, 28 Jul 2016 23:40:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Thu, 28 Jul 2016 23:40:40 -0700 (PDT) In-Reply-To: References: <1469618017-6534-1-git-send-email-ard.biesheuvel@linaro.org> <4A89E2EF3DFEDB4C8BFDE51014F606A1155E24F5@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Fri, 29 Jul 2016 08:40:40 +0200 Message-ID: To: "Gao, Liming" Cc: "edk2-devel@lists.01.org" , "lersek@redhat.com" , "Shi, Steven" , "Zhu, Yonghong" , "Justen, Jordan L" , "leif.lindholm@linaro.org" Subject: Re: [PATCH v4 0/7] BaseTools: add support for GCC5 in LTO mode X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 06:40:42 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 July 2016 at 08:09, Ard Biesheuvel wrote: > On 29 July 2016 at 06:47, Gao, Liming wrote: >> Ard: >> Thanks for your update. I have some comments for them. >> 1) It uses GCC as Link for GCC44-GCC49. Have you done verification on th= em? I verify GCC49 in OVMFIa32X64 platform. It works. > > Yes, I tested all of them. > >> 2) After this change, how to append new link option in platform DSC? Use= style -Wl, ? > > It depends. Some options (like -z) don't need it, but others do. > >> 3) I see GCC5 uses gcc-ar as its SLINK, and GCC49 uses ar as its SLINK. = Is gcc-ar required only by LTO? > > Yes > >> 4) Before GCC49 optimization, GCC49 means GCC49 or later, GCC5 can work = with GCC49 tool chain configuration. But now, I configure gcc to point to G= CC5, and build OVMF with GCC49 tool chain, it reports GenFw failure. I expe= ct GCC5 work with GCC49 and GCC5 tool chain both. GCC49 for no lto, GCC5 fo= r lto. I know Steven has provided the patch to fix this GenFw issue. >> >> GenFw: ERROR 3000: Invalid >> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC49/X64/MdeModulePk= g/Core/Dxe/DxeMain/DEBUG/DxeCore.dll unsupported ELF EM_X86_64 relocation 0= x9. >> GenFw: ERROR 3000: Invalid >> /home/hwu/work/lgao4/AllPkg/Build/Ovmf3264/DEBUG_GCC49/X64/MdeModulePk= g/Core/Dxe/DxeMain/DEBUG/DxeCore.dll unsupported ELF EM_X86_64 relocation 0= x9. >> GenFw: ERROR 3000: Invalid >> > > Which GCC version are you using? > I cannot reproduce this with gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.1) In any case, I think we should merge Steven's patch that adds handling to the relocation types to GenFw. The issue is only that having a GOT does not make a lot of sense for UEFI executables, since it forces a symbol reference to be absolute, which uses more space in the code, but also in the .reloc section. The visibility pragma I introduced for GCC4x was intended to prevent GOT based relocations from being emitted.