public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Gao, Liming" <liming.gao@intel.com>
Cc: "Shi, Steven" <steven.shi@intel.com>,
	"Zhu, Yonghong" <yonghong.zhu@intel.com>,
	 "Justen, Jordan L" <jordan.l.justen@intel.com>,
	 "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"lersek@redhat.com" <lersek@redhat.com>,
	 "leif.lindholm@linaro.org" <leif.lindholm@linaro.org>
Subject: Re: [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points
Date: Mon, 1 Aug 2016 18:11:59 +0200	[thread overview]
Message-ID: <CAKv+Gu-bK606pARbkyVWCF_gCkSDVTGEeqKGdsPmR-8Fd8hUeA@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu-EpR=tO7mWpTSQu1GbnEv7aW27+6b7=pwskED4Z2hSVQ@mail.gmail.com>

On 1 August 2016 at 17:51, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 1 August 2016 at 16:56, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 1 August 2016 at 16:49, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> On 1 August 2016 at 16:18, Gao, Liming <liming.gao@intel.com> 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 attribute 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      =
DEF(GCC48_ARM_ASLDLINK_FLAGS)
 DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)

 DEFINE GCC5_IA32_CC_FLAGS            = DEF(GCC49_IA32_CC_FLAGS) -flto
-fno-builtin
-DEFINE GCC5_X64_CC_FLAGS             = DEF(GCC49_X64_CC_FLAGS) -flto
-fno-builtin
+DEFINE GCC5_X64_CC_FLAGS             = DEF(GCC49_X64_CC_FLAGS) -flto
-fno-builtin -DUSING_LTO
 DEFINE GCC5_IA32_X64_DLINK_COMMON    = DEF(GCC49_IA32_X64_DLINK_COMMON)
 DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
 DEFINE GCC5_IA32_X64_DLINK_FLAGS     = 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 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.
+// 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.


  reply	other threads:[~2016-08-01 16:12 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-01  8:01 [PATCH v5 0/8] BaseTools: add support for GCC5 in LTO mode Ard Biesheuvel
2016-08-01  8:01 ` [PATCH v5 1/8] BaseTools CLANG35: drop problematic use-movt and save-temps options Ard Biesheuvel
2016-08-01  8:01 ` [PATCH v5 2/8] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: ignore .hash and .note sections Ard Biesheuvel
2016-08-01  8:01 ` [PATCH v5 3/8] BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into GCCLD Ard Biesheuvel
2016-08-01  8:01 ` [PATCH v5 4/8] BaseTools GCC: use 'gcc' as the linker command for GCC44 and later Ard Biesheuvel
2016-08-01  8:01 ` [PATCH v5 5/8] ArmPkg: add prebuilt glue binaries for GCC5 LTO support Ard Biesheuvel
2016-08-02  8:50   ` Leif Lindholm
2016-08-01  8:01 ` [PATCH v5 6/8] BaseTools GCC: drop GNU notes section from EFI image Ard Biesheuvel
2016-08-01  8:01 ` [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points Ard Biesheuvel
2016-08-01 14:18   ` Gao, Liming
2016-08-01 14:49     ` Ard Biesheuvel
2016-08-01 14:56       ` Ard Biesheuvel
2016-08-01 15:51         ` Ard Biesheuvel
2016-08-01 16:11           ` Ard Biesheuvel [this message]
2016-08-02  2:39             ` Gao, Liming
2016-08-02  5:26               ` Gao, Liming
2016-08-01  8:01 ` [PATCH v5 8/8] BaseTools GCC: introduce GCC5 toolchain to support GCC v5.x in LTO mode Ard Biesheuvel
2016-08-01 14:01 ` [PATCH v5 0/8] BaseTools: add support for GCC5 " Shi, Steven
2016-08-01 14:04   ` Ard Biesheuvel
2016-08-02  9:03 ` Ard Biesheuvel
2016-08-02 10:57   ` Laszlo Ersek
2016-08-02 11:13     ` Ard Biesheuvel
2016-08-02 11:41   ` Shi, Steven
2016-08-02 11:42     ` Ard Biesheuvel
2016-08-02 13:55       ` Michael Zimmermann
2016-08-02 13:56         ` Ard Biesheuvel
2016-08-02 14:39           ` Michael Zimmermann
2016-08-02 14:46             ` Michael Zimmermann
2016-08-02 14:51               ` Michael Zimmermann
2016-08-02 14:47             ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKv+Gu-bK606pARbkyVWCF_gCkSDVTGEeqKGdsPmR-8Fd8hUeA@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox