From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 1D91B21A16EEE for ; Tue, 20 Jun 2017 11:42:38 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id y25so63481029wrd.2 for ; Tue, 20 Jun 2017 11:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=SbYnLChH7zbXSKdE/+DJTN1/bqmx1MNL+qPLpt8d/dc=; b=bpbpss0Y87LaPF6okBtujHebvx28gr4msR4UMuLc1sK3eB7+JBmaqL8QvaRpxxRyWs t+PjldvSwGih41iqAyKs/MUswbRRgqmDKUnsZSmHc/LzakhJYfyacQnJneWEX5ufknMM fTIru0iHiJ6rlt6fG+A5OLqajJ4iAYoxRhf8w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=SbYnLChH7zbXSKdE/+DJTN1/bqmx1MNL+qPLpt8d/dc=; b=N0xsi/rbYdXI8ysnRwvDrsnwaMRo6OE9gT8EfEd2S784fEmAWOr4/ERSWmkMefEP7a lQaJyOS2DdQb0qcqwjGEs7MOCrDX9E/JkgrUZmEkWmcgW5eHMPKvCwptubgfBygzmbRK ACjxXKMFXKwxGhYkg5WxsoJCqUoVh7qFNsSjq0h0XNCh3ACFps3Gt3xZ0CjSwt4oe0cb /X3AFC2yyRWcKkeqCIap8zuGiBhITFSZQp8z6HzUYq/gBQLSmX5r0EyExHL7tpYoBqIV LqPv+/VgbP55SJ5lKvrk2yLM4xaTKenAc5FDj63fj1eriar1jVd9bUAvDH9rqDg8jZ0B mI7A== X-Gm-Message-State: AKS2vOxAiDDRqLdftoy1HXa9RW+1wVcHMut+mir5RM2GP69sy/XqR4oj Jgq06BpjhtpUfExLhMotxA== X-Received: by 10.80.183.4 with SMTP id g4mr22551643ede.138.1497984239441; Tue, 20 Jun 2017 11:43:59 -0700 (PDT) Received: from localhost.localdomain (ip16-2-212-87.adsl2.static.versatel.nl. [87.212.2.16]) by smtp.gmail.com with ESMTPSA id j40sm6422297ede.0.2017.06.20.11.43.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Jun 2017 11:43:58 -0700 (PDT) From: Ard Biesheuvel To: edk2-devel@lists.01.org, leif.lindholm@linaro.org, liming.gao@intel.com, yonghong.zhu@intel.com Cc: lersek@redhat.com, Ard Biesheuvel Date: Tue, 20 Jun 2017 20:43:54 +0200 Message-Id: <1497984234-19871-2-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1497984234-19871-1-git-send-email-ard.biesheuvel@linaro.org> References: <1497984234-19871-1-git-send-email-ard.biesheuvel@linaro.org> Subject: [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 18:42:38 -0000 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 -- 2.7.4