From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 9920A1A1E43 for ; Mon, 1 Aug 2016 09:12:00 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id b62so187343013iod.3 for ; Mon, 01 Aug 2016 09:12:00 -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=+51TuA7mYrW75wq0AMYLIR9e4R7xG5DAGOfiZySKag8=; b=jC+1n38f48frxNlvBNhcx+g8PeM6+0ESliwGIyc9UwLyOG7sf2E53dD8aNkQmwhOfo AwmT0BsbVMOjV5qDOujOXbukv2JPfW0OAfJJSy1ctIFpzpmAbIhjHcPBBw05mRJPohP5 AAQMmvF57zJIkFh4u4/ax6kjAw0ptZ/Q/WWeA= 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=+51TuA7mYrW75wq0AMYLIR9e4R7xG5DAGOfiZySKag8=; b=YqDNW6wbKv4Qzach3Ur79mnmjg+0CpGEgZq2GU8oLx/hjKGMAjtS6rmj7IS3NwFzOf 8FChpvUCmQbGL9GWOiGJV+BiAHNZLyuXEBzfWKvCny9bozz621xFaxc03ZfB0S00JwLw waf2DqmeK92eQBMTEZVrieaW67CxTjsO4uxmomWwfUbIVIZoekaoWKSeq3Ga3EmWp+jL 4BVN5FnvGrT8gY3yMB7FU01S/iPyN/1glHCVRoTqdlKUc6hjzf4arPWGkjOVjEL7Ed/F IeFixwE+E37ZEmwXXr7jmXJswpKhb7GpP/M4jD/tt8i13ngY1nJOqM+hIxil0SvobyL7 Nf3A== X-Gm-Message-State: AEkoouvCAx43Oxe4IiV3ebbi4u8kjFBSOx9yFybaz5a8DUP/x122JHgaCMauRNOvM1e0MjLZxboEF6t8rvCaejfL X-Received: by 10.107.135.22 with SMTP id j22mr65251796iod.56.1470067919847; Mon, 01 Aug 2016 09:11:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Mon, 1 Aug 2016 09:11:59 -0700 (PDT) In-Reply-To: References: <1470038497-2536-1-git-send-email-ard.biesheuvel@linaro.org> <1470038497-2536-8-git-send-email-ard.biesheuvel@linaro.org> <4A89E2EF3DFEDB4C8BFDE51014F606A1155E30DE@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Mon, 1 Aug 2016 18:11:59 +0200 Message-ID: To: "Gao, Liming" Cc: "Shi, Steven" , "Zhu, Yonghong" , "Justen, Jordan L" , "edk2-devel@lists.01.org" , "lersek@redhat.com" , "leif.lindholm@linaro.org" Subject: Re: [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 16:12:00 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1 August 2016 at 17:51, Ard Biesheuvel wrote= : > On 1 August 2016 at 16:56, Ard Biesheuvel wro= te: >> On 1 August 2016 at 16:49, Ard Biesheuvel wr= ote: >>> On 1 August 2016 at 16:18, Gao, Liming wrote: >>>> Ard: >>>> I don't think it is good way to define GCC_VISIBILITY_PROTECTED and = apply it in EntryPointLib. We only need to expose _ModuleEntryPoint. It has= been specified in LINK_FLAGS in tools_def.txt. Could we also specify its a= ttribute in CC_FLAGS or LINK_FLAGS in tools_def.txt? >>>> >>> >>> It seems this does the trick as well >>> >>> diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.= lds >>> index 281af8a9bd33..02387d4f8d6f 100644 >>> --- a/BaseTools/Scripts/GccBase.lds >>> +++ b/BaseTools/Scripts/GccBase.lds >>> @@ -80,3 +80,7 @@ SECTIONS { >>> *(COMMON) >>> } >>> } >>> + >>> +VERSION { >>> + { global: _ModuleEntryPoint*; }; >>> +}; >>> >>> >>> Note that * at the end: this is necessary since _ModuleEntryPoint will >>> be called _ModuleEntryPoint.lto_priv.xxx in the LTO objects. >>> >> >> Hmm, looks like I spoke too soon. I don't know what I did wrong, but >> this does not actually work. >> > > The only alternative I can think of is to add a static non-lto object > to the tree that refers to _ModuleEntryPoint, similar to the way I > handle the ARM intrinsics in patch #5 > As it turns out, the LTO linker does not need to visibility pragma to prevent it from emitting GOT based relocations. This makes sense, considering that the LTO linker can see that no symbol references are ever satisfied across dynamic object boundaries. That means I could work around this in the following way: diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 314adaf6bfa8..983e2fea7390 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -4462,7 +4462,7 @@ DEFINE GCC49_ARM_ASLDLINK_FLAGS =3D DEF(GCC48_ARM_ASLDLINK_FLAGS) DEFINE GCC49_AARCH64_ASLDLINK_FLAGS =3D DEF(GCC48_AARCH64_ASLDLINK_FLAGS) DEFINE GCC5_IA32_CC_FLAGS =3D DEF(GCC49_IA32_CC_FLAGS) -flto -fno-builtin -DEFINE GCC5_X64_CC_FLAGS =3D DEF(GCC49_X64_CC_FLAGS) -flto -fno-builtin +DEFINE GCC5_X64_CC_FLAGS =3D DEF(GCC49_X64_CC_FLAGS) -flto -fno-builtin -DUSING_LTO DEFINE GCC5_IA32_X64_DLINK_COMMON =3D DEF(GCC49_IA32_X64_DLINK_COMMON) DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS =3D DEF(GCC49_IA32_X64_ASLDLINK_FLAGS= ) DEFINE GCC5_IA32_X64_DLINK_FLAGS =3D DEF(GCC49_IA32_X64_DLINK_FLAGS) -= flto diff --git a/MdePkg/Include/X64/ProcessorBind.h b/MdePkg/Include/X64/ProcessorBind.h index 666cc8e8bd16..77fab7055afc 100644 --- a/MdePkg/Include/X64/ProcessorBind.h +++ b/MdePkg/Include/X64/ProcessorBind.h @@ -27,12 +27,15 @@ #pragma pack() #endif -#if defined(__GNUC__) && defined(__pic__) +#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO) // // Mark all symbol declarations and references as hidden, meaning they wil= l // not be subject to symbol preemption. This allows the compiler to refer = to // symbols directly using relative references rather than via the GOT, whi= ch // contains absolute symbol addresses that are subject to runtime relocati= on. +// The LTO linker will not emit GOT based relocations anyway, so there is = no +// need to set the pragma in that case (and doing so will cause issues of = its +// own) // #pragma GCC visibility push (hidden) #endif and I can drop this patch.