From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::22b; helo=mail-io0-x22b.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 8D58921B00DEB for ; Thu, 16 Nov 2017 07:41:01 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id g73so5636262ioj.8 for ; Thu, 16 Nov 2017 07:45:11 -0800 (PST) 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=1/6Plll+JzIppwR4f90yBHaOi6ieom+FlKXi2BMJhr4=; b=C1Keq6jfrOvSW0Xm5LBoG+EiyoyxHW45ZLVlIAUleX8szTq15594AJiM3/DldNPr9I mMiXhRu7bkGRO6OdwjUoNbm7Kk899lh8KXSBTcsa3+CN8fX81U4WRikGIrpnHl94sOX3 Tsqvw4deWJjoI2ZR80eZKUjGruz6Anpp7Q6rw= 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=1/6Plll+JzIppwR4f90yBHaOi6ieom+FlKXi2BMJhr4=; b=E5uGsyKuQK8Ug8SPg0pFH1n6tsZVKFCVgzW5tdIcpnicRl85vaRMh4r58b331touXx mGBOpUwUYijYptNHXBGVSl71rdoz1b/NvVdw6nkApn3STqsUN7UilMlWgD15CWhY9+e4 FRVkabev0eRZF4c+x+3ko9POVC+NhQFoHbzjC1f7XCqG7l6OyRYuRwbuUjAWrRXPGo5d cn0NFtPh0WBAzoucwshEe13LNmQ7SKLf5JPnabNmpgPZkufihKgtkuCLUoRDx4cfWsGH APrKaNunOkaSjRwt4pd49wbe4AHz0vgkF5Q7QxPOmeye005q1rmnq4pZuHUU3iY5qEC4 ibyw== X-Gm-Message-State: AJaThX4JVivjsGKdPQTjms1s8/ZKJNilb/4g7YVaswGhVnF9AH4jCEl0 43oIT+4VSvZy8is6ab8S7DAW5xvxZNMdog61NDU2dw== X-Google-Smtp-Source: AGs4zMbP/Wsit1Ta50Q6BLhMbTSnalN+G81jGSjpxp6ygTyzCJq/RwwITxsBw9S1CKZpuIXpBT9yGiemUplmGHElmS0= X-Received: by 10.107.174.206 with SMTP id n75mr2038336ioo.43.1510847110699; Thu, 16 Nov 2017 07:45:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.3 with HTTP; Thu, 16 Nov 2017 07:45:10 -0800 (PST) In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E17F48B@SHSMSX104.ccr.corp.intel.com> References: <20171101150125.13679-1-ard.biesheuvel@linaro.org> <4A89E2EF3DFEDB4C8BFDE51014F606A14E176A26@SHSMSX104.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E17F48B@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Thu, 16 Nov 2017 15:45:10 +0000 Message-ID: To: "Gao, Liming" Cc: Marcin Wojtas , "edk2-devel@lists.01.org" , "daniel.thompson@linaro.org" , "leif.lindholm@linaro.org" Subject: Re: [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources 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, 16 Nov 2017 15:41:01 -0000 Content-Type: text/plain; charset="UTF-8" On 16 November 2017 at 15:31, Gao, Liming wrote: > Ard: > Does this error only happen on ACPI table compiling? But, I see -no-pie is also in normal DLINK flag. Why is the driver not compiled failed? > The main difference is that the ACPI tables don't tolerate any padding at the start of the binary image. This is different for ELF binaries that are converted to PE/COFF, given that the entry point is exposed in the header, so the padding is just ignored. However, we should still try to omit those sections if we can. >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >> Sent: Thursday, November 16, 2017 11:09 PM >> To: Marcin Wojtas >> Cc: Gao, Liming ; edk2-devel@lists.01.org; daniel.thompson@linaro.org; leif.lindholm@linaro.org >> Subject: Re: [edk2] [PATCH] BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources >> >> On 16 November 2017 at 15:07, Marcin Wojtas wrote: >> > Hi Ard, >> > >> > 2017-11-16 15:48 GMT+01:00 Ard Biesheuvel : >> >> On 16 November 2017 at 14:38, Marcin Wojtas wrote: >> >>> Hi Ard, >> >>> >> >>> With both PIE disabling patches for AARCH64, when compiling ACPI tables with >> >>> gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- >> >>> I get following errors: >> >>> [...] >> >>> aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie' >> >>> Do I understand correctly, that I should either revert those patches >> >>> or upgrade to the newer toolchain? >> >>> >> >> >> >> Ugh. >> >> >> >> I thought GCC 5 and later implemented -no-pie, but apparently not. >> >> >> >> Does this fix your build? I will need to check whether it fixes the >> >> original issue, but hopefully your toolchain doesn't choke on this: >> >> >> >> diff --git a/BaseTools/Conf/tools_def.template >> >> b/BaseTools/Conf/tools_def.template >> >> index aebd7d558633..111fe8da7773 100755 >> >> --- a/BaseTools/Conf/tools_def.template >> >> +++ b/BaseTools/Conf/tools_def.template >> >> @@ -4496,10 +4496,10 @@ DEFINE GCC5_AARCH64_CC_FLAGS = >> >> DEF(GCC49_AARCH64_CC_FLAGS) >> >> DEFINE GCC5_AARCH64_CC_XIPFLAGS = DEF(GCC49_AARCH64_CC_XIPFLAGS) >> >> DEFINE GCC5_ARM_DLINK_FLAGS = DEF(GCC49_ARM_DLINK_FLAGS) -no-pie >> >> DEFINE GCC5_ARM_DLINK2_FLAGS = DEF(GCC49_ARM_DLINK2_FLAGS) -Wno-error >> >> -DEFINE GCC5_AARCH64_DLINK_FLAGS = DEF(GCC49_AARCH64_DLINK_FLAGS) -no-pie >> >> +DEFINE GCC5_AARCH64_DLINK_FLAGS = DEF(GCC49_AARCH64_DLINK_FLAGS) >> >> -Wl,-no-pie >> >> DEFINE GCC5_AARCH64_DLINK2_FLAGS = >> >> DEF(GCC49_AARCH64_DLINK2_FLAGS) -Wno-error >> >> DEFINE GCC5_ARM_ASLDLINK_FLAGS = DEF(GCC49_ARM_ASLDLINK_FLAGS) -no-pie >> >> -DEFINE GCC5_AARCH64_ASLDLINK_FLAGS = >> >> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -no-pie >> >> +DEFINE GCC5_AARCH64_ASLDLINK_FLAGS = >> >> DEF(GCC49_AARCH64_ASLDLINK_FLAGS) -Wl,-no-pie >> >> >> >> #################################################################################### >> >> # >> >> >> > >> > Unfortunately no change, still: >> > aarch64-linux-gnu-gcc: error: unrecognized command line option '-no-pie' >> > In order to make sure, I double checked twice cleaninig everything and >> > rebuilding from scratch. >> > >> >> Thanks, but it doesn't matter anyway: it doesn't fix the original >> issues on affected toolchains. >> >> It appears the only way we can deal with this is introducing GCC6 and >> move the workaround there. >> >> Thanks, >> Ard.