From patchwork Wed Jul 13 15:57:17 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 71934 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp1077305qga; Wed, 13 Jul 2016 08:57:20 -0700 (PDT) X-Received: by 10.66.254.196 with SMTP id ak4mr14869258pad.62.1468425440913; Wed, 13 Jul 2016 08:57:20 -0700 (PDT) Return-Path: Received: from ml01.01.org (ml01.01.org. [198.145.21.10]) by mx.google.com with ESMTPS id p88si941305pfi.197.2016.07.13.08.57.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 08:57:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) client-ip=198.145.21.10; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 061581A1EE0; Wed, 13 Jul 2016 08:58:06 -0700 (PDT) X-Original-To: edk2-devel@lists.01.org Delivered-To: edk2-devel@lists.01.org Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 A6A401A1E27 for ; Wed, 13 Jul 2016 08:58:04 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id h190so47740715ith.1 for ; Wed, 13 Jul 2016 08:57:18 -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=Goo0IqS4e1p7aS2QPpyh91tEo8ln+QCinDq/zkO3zc8=; b=X3L/EaCuUrEsCKw0W6Xa4mx/xuxYiwhcPJPkiDx5kXeyMqPfiA/aMcM1fMwrOLWEWy FMc16okQRFIbZ5BPsMqHogXTDN5oMUpYigJ28stbjiL6GxXlZJb/CdYRWlurYdBR8zcw WkHsOGGxynskShC2/Wc489jcEe4KAT/05QCYY= 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=Goo0IqS4e1p7aS2QPpyh91tEo8ln+QCinDq/zkO3zc8=; b=HwnvSx68xvFiRMIG4Lku2VCpTCJ4BEnGh+MEXcAL7vQ/kWEvd6QBUL45j0CV0A6zoh Q2AHqc8heIk+z331r3WtszANAzzPxig3rIyzukJdFO01bLaiqIGaSbRKllS6AbkPjq7B PZJ7RzA8LaO5Jk6Ja6aLc9FMM2g+SOlnzH4KQSAPNe3WDmRvP4HyAL8St+x7K9Rr3dw5 OPPt0biekkcze8g1gQnpDmqzFWUF2Ct3wnDNR7t3eJmDTBQ7K3Lb3tUlld+vhDzJBmPp jf57frNRDsFGVHl12SJ/Kfh33Ws3276xkdvSrHmM6eLTa4lmJQfBkBRr17+2N1pfJO0x KQwg== X-Gm-Message-State: ALyK8tLk9AlfyAEaPDJgFtvcOEzBaHCkyyVZsoFlFswZ+FjXwdAZDrh0qYjOJ3hGyFJEXt8npV7MBq2mfGTJ8XJp X-Received: by 10.36.107.88 with SMTP id v85mr9495447itc.51.1468425438275; Wed, 13 Jul 2016 08:57:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.214.6 with HTTP; Wed, 13 Jul 2016 08:57:17 -0700 (PDT) In-Reply-To: References: <1467967364-11556-1-git-send-email-steven.shi@intel.com> <1467967364-11556-4-git-send-email-steven.shi@intel.com> From: Ard Biesheuvel Date: Wed, 13 Jul 2016 17:57:17 +0200 Message-ID: To: "Shi, Steven" Subject: Re: [edk2] [PATCH v2 3/7] MdePkg: Enable new MS VA intrinsics for GNUC x86 64bits build X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Kinney, Michael D" , Jordan Justen , edk2-devel-01 , "afish@apple.com" , "Gao, Liming" Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" On 13 July 2016 at 16:35, Ard Biesheuvel wrote: > On 8 July 2016 at 10:42, Shi, Steven wrote: >> Both GCC and LLVM 3.8 64bits support new variable argument (VA) >> intrinsics for Microsoft ABI, enable these new VA intrinsics for >> GNUC family 64bits code build. These VA intrinsics are only >> permitted use in 64bits code, so not use them in 32bits code build. >> The original 32bits GNU VA intrinsics has the same calling conversion >> as MS, so we don’t need change them. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Steven Shi >> --- >> MdePkg/Include/Base.h | 27 +++++++++++++++++++++++++-- >> 1 file changed, 25 insertions(+), 2 deletions(-) >> mode change 100644 => 100755 MdePkg/Include/Base.h >> >> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h >> old mode 100644 >> new mode 100755 >> index cbd9e55..5129b64 >> --- a/MdePkg/Include/Base.h >> +++ b/MdePkg/Include/Base.h >> @@ -588,9 +588,32 @@ struct _LIST_ENTRY { >> >> #define VA_COPY(Dest, Start) __va_copy (Dest, Start) >> >> -#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) >> + >> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && !defined (MDE_CPU_IA32) > > This will affect all other architectures as well, so you should > probably change the second proposition to > > defined(MDE_CPU_X64) > > instead. > > >> +// >> +// 64bits build only. Use GCC built-in macros for variable argument lists. >> +// >> +/// >> +/// Both GCC and LLVM 3.8 64bits support new variable argument intrinsics for Microsoft ABI >> +/// >> + >> +/// >> +/// Variable used to traverse the list of arguments. This type can vary by >> +/// implementation and could be an array or structure. >> +/// >> +typedef __builtin_ms_va_list VA_LIST; >> + >> +#define VA_START(Marker, Parameter) __builtin_ms_va_start (Marker, Parameter) >> + >> +#define VA_ARG(Marker, TYPE) ((sizeof (TYPE) < sizeof (UINTN)) ? (TYPE)(__builtin_va_arg (Marker, UINTN)) : (TYPE)(__builtin_va_arg (Marker, TYPE))) >> + >> +#define VA_END(Marker) __builtin_ms_va_end (Marker) >> + >> +#define VA_COPY(Dest, Start) __builtin_ms_va_copy (Dest, Start) >> + >> +#elif defined(__GNUC__) && !defined(NO_BUILTIN_VA_FUNCS) && defined (MDE_CPU_IA32) > > likewise here > >> // >> -// Use GCC built-in macros for variable argument lists. >> +// 32bits build only. Use GCC built-in macros for variable argument lists. >> // >> > > Note that with this change alone, I managed to build EmulatorPkg/X64 > and Ovmf/X64 successfully using '-fpic -mcmodel=small -O2' (and > removing -DNO_BUILTIN_VA_FUNCS), using versions of GCC all the way > back to v4.7.4, which results in much smaller binaries. OK, that is not entirely true. To support -fpic code (but linked without -pie) you will also need either your patch BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code or the following hunk """ """ Note that there is no benefit to having a GOT in a bare metal binary: it only increases the number of absolute references, and binaries are not shared between processes, which means there is no need to concentrate relocatable quantities in as few pages as possible in order to keep the remaining pages clean. --- a/MdePkg/Include/X64/ProcessorBind.h +++ b/MdePkg/Include/X64/ProcessorBind.h @@ -27,6 +27,16 @@ #pragma pack() #endif +#if defined(__GNUC__) && defined(__pic__) +// +// Mark all symbol declarations and references as hidden, meaning they will not +// be exported from a shared library, and thus will not be subject to symbol +// preemption. This allows the compiler to refer to symbols directly using +// relative references rather than via the GOT, which contains absolute symbol +// addresses that are subject to runtime relocation. +// +#pragma GCC visibility push (hidden) +#endif #if defined(__INTEL_COMPILER) //