From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id EAE2821A16EC1 for ; Tue, 20 Jun 2017 12:24:38 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 63E2364F4; Tue, 20 Jun 2017 19:26:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 63E2364F4 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 63E2364F4 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-150.phx2.redhat.com [10.3.116.150]) by smtp.corp.redhat.com (Postfix) with ESMTP id 059A88CCC4; Tue, 20 Jun 2017 19:25:59 +0000 (UTC) To: Ard Biesheuvel , edk2-devel@lists.01.org, leif.lindholm@linaro.org, liming.gao@intel.com, yonghong.zhu@intel.com References: <1497984234-19871-1-git-send-email-ard.biesheuvel@linaro.org> <1497984234-19871-2-git-send-email-ard.biesheuvel@linaro.org> From: Laszlo Ersek Message-ID: <88cc1eed-2f64-772d-a4bc-20ffc7b02e0a@redhat.com> Date: Tue, 20 Jun 2017 21:25:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1497984234-19871-2-git-send-email-ard.biesheuvel@linaro.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 20 Jun 2017 19:26:01 +0000 (UTC) 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: Tue, 20 Jun 2017 19:24:39 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/20/17 20:43, 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. > > 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 > --- > 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 > Acked-by: Laszlo Ersek