From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: edk2-devel@lists.01.org
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Michael D Kinney <michael.d.kinney@intel.com>,
Liming Gao <liming.gao@intel.com>, Ruiyu Ni <ruiyu.ni@intel.com>,
Hao Wu <hao.a.wu@intel.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Jordan Justen <jordan.l.justen@intel.com>,
Andrew Fish <afish@apple.com>, Star Zeng <star.zeng@intel.com>,
Eric Dong <eric.dong@intel.com>, Laszlo Ersek <lersek@redhat.com>,
Zenith432 <zenith432@users.sourceforge.net>,
"Shi, Steven" <steven.shi@intel.com>
Subject: [RFC PATCH 00/11] GCC/X64: use hidden visibility for LTO PIE code
Date: Tue, 12 Jun 2018 17:22:55 +0200 [thread overview]
Message-ID: <20180612152306.25998-1-ard.biesheuvel@linaro.org> (raw)
The GCC toolchain uses PIE mode when building code for X64, because it
is the most efficient in size: it uses relative references where
possible, but still uses 64-bit quantities for absolute symbol
references, which is optimal for executables that need to be converted
to PE/COFF using GenFw.
Enabling PIE mode has a couple of side effects though, primarily caused
by the fact that the primary application area of GCC is to build programs
for userland. GCC will assume that ELF symbols should be preemptible (which
makes sense for PIC but not for PIE, but this simply seems to be the result
of code being shared between the two modes), and it will attempt to keep
absolute references close to each other so that dynamic relocations that
trigger CoW for text pages have the smallest possible footprint.
These side effects can be mititgated by overriding the visibility of all
symbol definitions *and* symbol references, using a special #pragma. This
will inform the compiler that symbol preemption and dynamic relocations
are not a concern, and that all symbol references can be emitted as direct
relative references rather than relative references to a GOT entry containing
the absolute address. Unsurprisingly, this leads to better and smaller code.
Unfortunately, we have not been able to set this override when LTO is in
effect, because the LTO code generator infers from the hidden visibility
of all symbols that none of the code is reachable, and discards it all,
leading to corrupt, empty binaries.
We can work around this by overriding the visibility for symbols that are
module entry points. So implement this for all occcurrences of the symbol
'_ModuleEntryPoint', and enable 'hidden' visibility in LTO builds as well.
Note that all the changes in this series resolve to no-ops if USING_LTO
is not #defined.
Code can be found here:
https://github.com/ardbiesheuvel/edk2/tree/x64-lto-visibility
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Zenith432 <zenith432@users.sourceforge.net>
Cc: "Shi, Steven" <steven.shi@intel.com>
Ard Biesheuvel (11):
MdePkg/ProcessorBind.h: define macro to decorate module entry points
DuetPkg: annotate module entry points with EFI_ENTRYPOINT
EdkCompatibilityPkg: annotate module entry points with EFI_ENTRYPOINT
EmbeddedPkg: annotate module entry points with EFI_ENTRYPOINT
EmulatorPkg: annotate module entry points with EFI_ENTRYPOINT
IntelFrameWorkPkg: annotate module entry points with EFI_ENTRYPOINT
MdeModulePkg: annotate module entry points with EFI_ENTRYPOINT
MdePkg: annotate module entry points with EFI_ENTRYPOINT
Nt32Pkg: annotate module entry points with EFI_ENTRYPOINT
UefiCpuPkg: annotate module entry points with EFI_ENTRYPOINT
MdePkg/ProcessorBind.h X64: drop non-LTO limitation on visiblity
override
DuetPkg/DxeIpl/DxeInit.c | 1 +
DuetPkg/EfiLdr/EfiLoader.c | 1 +
.../EntryPoints/EdkIIGlueDxeDriverEntryPoint.c | 1 +
.../EntryPoints/EdkIIGluePeimEntryPoint.c | 1 +
.../EntryPoints/EdkIIGlueSmmDriverEntryPoint.c | 1 +
.../Library/EdkIIGlueDxeSmmDriverEntryPoint.h | 1 +
.../Include/Library/EdkIIGluePeimEntryPoint.h | 1 +
.../Library/EdkIIGlueUefiDriverEntryPoint.h | 1 +
EmbeddedPkg/TemplateSec/TemplateSec.c | 1 +
EmulatorPkg/Sec/Sec.c | 1 +
.../DxeSmmDriverEntryPoint/DriverEntryPoint.c | 1 +
MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c | 1 +
MdePkg/Include/Base.h | 7 +++++++
MdePkg/Include/Library/DxeCoreEntryPoint.h | 1 +
MdePkg/Include/Library/PeiCoreEntryPoint.h | 1 +
MdePkg/Include/Library/PeimEntryPoint.h | 1 +
.../Include/Library/UefiApplicationEntryPoint.h | 1 +
MdePkg/Include/Library/UefiDriverEntryPoint.h | 1 +
MdePkg/Include/X64/ProcessorBind.h | 16 +++++++++++-----
.../DxeCoreEntryPoint/DxeCoreEntryPoint.c | 1 +
.../PeiCoreEntryPoint/PeiCoreEntryPoint.c | 1 +
MdePkg/Library/PeimEntryPoint/PeimEntryPoint.c | 1 +
.../ApplicationEntryPoint.c | 1 +
.../UefiDriverEntryPoint/DriverEntryPoint.c | 1 +
Nt32Pkg/Sec/SecMain.c | 1 +
.../PlatformSecLibNull/PlatformSecLibNull.c | 1 +
26 files changed, 42 insertions(+), 5 deletions(-)
--
2.17.1
next reply other threads:[~2018-06-12 15:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-12 15:22 Ard Biesheuvel [this message]
2018-06-12 15:22 ` [RFC PATCH 01/11] MdePkg/ProcessorBind.h: define macro to decorate module entry points Ard Biesheuvel
2018-06-12 15:22 ` [RFC PATCH 02/11] DuetPkg: annotate module entry points with EFI_ENTRYPOINT Ard Biesheuvel
2018-06-12 15:22 ` [RFC PATCH 03/11] EdkCompatibilityPkg: " Ard Biesheuvel
2018-06-12 15:22 ` [RFC PATCH 04/11] EmbeddedPkg: " Ard Biesheuvel
2018-06-12 15:23 ` [RFC PATCH 05/11] EmulatorPkg: " Ard Biesheuvel
2018-06-12 15:23 ` [RFC PATCH 06/11] IntelFrameWorkPkg: " Ard Biesheuvel
2018-06-12 15:23 ` [RFC PATCH 07/11] MdeModulePkg: " Ard Biesheuvel
2018-06-12 15:23 ` [RFC PATCH 08/11] MdePkg: " Ard Biesheuvel
2018-06-12 15:23 ` [RFC PATCH 09/11] Nt32Pkg: " Ard Biesheuvel
2018-06-12 15:23 ` [RFC PATCH 10/11] UefiCpuPkg: " Ard Biesheuvel
2018-06-12 15:23 ` [RFC PATCH 11/11] MdePkg/ProcessorBind.h X64: drop non-LTO limitation on visiblity override Ard Biesheuvel
2018-06-12 18:33 ` [RFC PATCH 00/11] GCC/X64: use hidden visibility for LTO PIE code Laszlo Ersek
2018-06-12 18:58 ` Ard Biesheuvel
2018-06-13 2:08 ` Shi, Steven
[not found] <1142041495.4269416.1528831046054.ref@mail.yahoo.com>
2018-06-12 19:17 ` Zenith432
[not found] <1971023844.4599916.1528877047633.ref@mail.yahoo.com>
2018-06-13 8:04 ` Zenith432
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=20180612152306.25998-1-ard.biesheuvel@linaro.org \
--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