From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 174F821CA3585 for ; Thu, 22 Jun 2017 04:08:13 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id m62so48603780itc.0 for ; Thu, 22 Jun 2017 04:09:37 -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=JXEJb/PdnKezGsvZefEmfCCF+kidH2FU/Kzabk2iZWk=; b=KUZL9P/RUvguE0+6/krrPsNRk+d3VsGSGJohbedS6NqUs7mcDVKxhIfU6SLf1kq3Ee HDtttG3F4qtQvBFNpSzX2So+2rLkJrpCrkU1eyNwe/9eyuhppF1eHqJcKp9rdaLq1FkT LWiKOUaGq2dCzmwQMOia+eroUYkWNd9KPbSjM= 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=JXEJb/PdnKezGsvZefEmfCCF+kidH2FU/Kzabk2iZWk=; b=h92WnPkH6NhwKhTlvV0Q9l3FHIgaeV66nQG8MEEa9knQ7wctiiVr/qjz8ZwcImYmZn 00sjpErtvNqiz9cIVqe3O37Y8+rSR1eRLRQLydRakuxm1u/PyzzsLuHdKvDVbZda+NiS 4MFiB7EBxCBnmjzbITd3vSpKE+RsTrQ0D9V1bLtXKVPLbUNEmFqqoyhglx1oiHgrTb+7 5UmswCEeajvnCBj68wrcjt4AOw4/n7OjdYwSLP8KJth5t7S0q9EjQFh5ZGiMmOfjc0iN 6185j9ygjdUGCCgvHJ+9LUSJu/8p8jHh3QF0hNb+18jGMbuxkVFs6dJ6gWxDuqapznxQ D7Xg== X-Gm-Message-State: AKS2vOy2AXhZs9cNav5FD+lI+ynF2gRMGLRJMwFN3M5gap5tg9AHOsfO HsBRL/k82Q4SFXBxPLyXNoC1D+VcqZDy+Xi+iw== X-Received: by 10.36.26.21 with SMTP id 21mr1449721iti.6.1498129777319; Thu, 22 Jun 2017 04:09:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.76 with HTTP; Thu, 22 Jun 2017 04:09:36 -0700 (PDT) In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14D74C867@shsmsx102.ccr.corp.intel.com> References: <1497984234-19871-1-git-send-email-ard.biesheuvel@linaro.org> <1497984234-19871-2-git-send-email-ard.biesheuvel@linaro.org> <20170620195948.GC26676@bivouac.eciton.net> <4A89E2EF3DFEDB4C8BFDE51014F606A14D74C867@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Thu, 22 Jun 2017 11:09:36 +0000 Message-ID: To: "Gao, Liming" Cc: Leif Lindholm , "edk2-devel@lists.01.org" , "Zhu, Yonghong" , "lersek@redhat.com" Subject: Re: [PATCH 2/2] BaseTools/tools_def: AARCH64: disable LTO type mismatch warnings 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: Thu, 22 Jun 2017 11:08:13 -0000 Content-Type: text/plain; charset="UTF-8" On 21 June 2017 at 02:11, Gao, Liming wrote: > Reviewed-by: Liming Gao > Thanks, pushed as 9ba8baae15ca >>-----Original Message----- >>From: Leif Lindholm [mailto:leif.lindholm@linaro.org] >>Sent: Wednesday, June 21, 2017 4:00 AM >>To: Ard Biesheuvel >>Cc: edk2-devel@lists.01.org; Gao, Liming ; Zhu, >>Yonghong ; lersek@redhat.com >>Subject: Re: [PATCH 2/2] BaseTools/tools_def: AARCH64: disable LTO type >>mismatch warnings >> >>On Tue, Jun 20, 2017 at 08:43:54PM +0200, Ard Biesheuvel wrote: >>> On AARCH64, any code that may execute with the MMU off needs to be >>built >>> with -mstrict-align, given that unaligned accesses are not allowed unless >>> the MMU is enabled. This does not only affect SEC and PEI modules, but >>> also static libraries of the BASE type, which may be linked into such >>> modules, as well as into modules of other types. As it turns out, the >>> presence of -mstrict-align is reflected in the internal representations >>> of the types defined in those libraries. >>> >>> When -fstrict-aliasing is passed to GCC, it assumes that pointers to >>> objects of different types cannot refer to the same memory location, and >>> attempts to exploit this fact when optimizing the code. Since such >>> assumptions are only valid under very strict conditions which are not >>> guaranteed to be met in EDK2, we disable this optimization by passing >>> -fno-strict-aliasing by default. >> >>Just a comment - you don't necessarily have to update this excellent >>commit mesage, but: >>-fstrict-aliasing is GCC default, because it is a restriction in the C >>language. Because it's a bit non-obvious, things can go hilariously >>wrong in very non-obvious ways, and the potential optimization gains >>are ulikely to be generally relevant, -fno-strict-aliasing is a >>sensible thing to always have set (like we do). >> >>> When LTO is in effect, this applies equally to the code generation that >>> may occur at link time, which is why the linker warns about unexpected >>> differences in type definitions between the intermediate representations >>> that are present in the object files being linked. This may result in >>> warnings such as the one below, even if -fno-strict-aliasing is used: >>> >>> MdePkg/Include/Library/BaseLib.h:1712:1: >>> warning: type of 'StrToGuid' does not match original declaration >>> [-Wlto-type-mismatch] >>> StrToGuid ( >>> ^ >>> MdePkg/Library/BaseLib/SafeString.c:1506:1: >>> note: 'StrToGuid' was previously declared here >>> StrToGuid ( >>> ^ >>> MdePkg/Library/BaseLib/SafeString.c:1506:1: >>> note: code may be misoptimized unless -fno-strict-aliasing is used >>> >>> This warning is inadvertently triggered when linking BASE libraries built >>> with -mstrict-align into modules of types other than SEC or PEI, since the >>> types are subtly different, even though the use of code that maintains >>> strict alignment in a module that does not care about this is unlikely to >>> cause problems. And even if it did, it would still only affect code built >>> with -fstrict-aliasing enabled, which we disable unconditionally. So let's >>> just silence the warning by passing -Wno-lto-type-mismatch. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.0 >>> Signed-off-by: Ard Biesheuvel >> >>Reviewed-by: Leif Lindholm >> >>> --- >>> BaseTools/Conf/tools_def.template | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/BaseTools/Conf/tools_def.template >>b/BaseTools/Conf/tools_def.template >>> index 7a58ce365ed2..9a3ba9defb12 100755 >>> --- a/BaseTools/Conf/tools_def.template >>> +++ b/BaseTools/Conf/tools_def.template >>> @@ -5407,7 +5407,7 @@ RELEASE_GCC5_ARM_DLINK_FLAGS = >>DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKS >>> DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20 >>> >>> RELEASE_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) - >>flto -Wno-unused-but-set-variable -mcmodel=tiny -fomit-frame-pointer >>> -RELEASE_GCC5_AARCH64_DLINK_FLAGS = >>DEF(GCC5_AARCH64_DLINK_FLAGS) -flto -Os - >>L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 -Wl,-plugin-opt=-pass- >>through=-llto-aarch64 >>> +RELEASE_GCC5_AARCH64_DLINK_FLAGS = >>DEF(GCC5_AARCH64_DLINK_FLAGS) -flto -Os - >>L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 -Wl,-plugin-opt=-pass- >>through=-llto-aarch64 -Wno-lto-type-mismatch >>> >>> NOOPT_GCC5_AARCH64_CC_FLAGS = DEF(GCC5_AARCH64_CC_FLAGS) - >>O0 -mcmodel=small >>> NOOPT_GCC5_AARCH64_DLINK_FLAGS = >>DEF(GCC5_AARCH64_DLINK_FLAGS) -z common-page-size=0x1000 -O0 >>> -- >>> 2.7.4 >>>