From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.93; helo=mga11.intel.com; envelope-from=steven.shi@intel.com; receiver=edk2-devel@lists.01.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3709D212B7D88 for ; Tue, 12 Jun 2018 19:08:28 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2018 19:08:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,217,1526367600"; d="scan'208";a="47297320" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga008.fm.intel.com with ESMTP; 12 Jun 2018 19:08:28 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 12 Jun 2018 19:08:28 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 12 Jun 2018 19:08:27 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.223]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.70]) with mapi id 14.03.0319.002; Wed, 13 Jun 2018 10:08:23 +0800 From: "Shi, Steven" To: Ard Biesheuvel , Zenith432 CC: "Kinney, Michael D" , "Gao, Liming" , "Ni, Ruiyu" , "Wu, Hao A" , Leif Lindholm , "Justen, Jordan L" , Andrew Fish , "Zeng, Star" , "Dong, Eric" , Laszlo Ersek , "edk2-devel@lists.01.org" Thread-Topic: [RFC PATCH 00/11] GCC/X64: use hidden visibility for LTO PIE code Thread-Index: AQHUAmFS7eBiyIJat0mzHD4Fd6LCtKRda92g Date: Wed, 13 Jun 2018 02:08:23 +0000 Message-ID: <06C8AB66E78EE34A949939824ABE2B313B76E3AB@shsmsx102.ccr.corp.intel.com> References: <20180612152306.25998-1-ard.biesheuvel@linaro.org> In-Reply-To: <20180612152306.25998-1-ard.biesheuvel@linaro.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmIyMjk3YmItM2RlOC00NThhLWFjOWQtZmIyMWE5ODk4ZWMxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUmMwNEp0UVdLbDVvaWNGZzdnMjFZalNvS2pHdm1XQ3Zya1Z4S0pIZGliK0Nwb2FcL041Y2RJRVc4VTZhYUJWbDEifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [RFC PATCH 00/11] GCC/X64: use hidden visibility for LTO PIE code X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 02:08:29 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ard, Zenith, Thank you both explained the complete knowledge about ELF GOT, LTO, PIC/PIE= , machine code mode and GCC visibility #pragma. It is pretty good to read t= hem all in one picture. And I believe copying these explain to a edk2 wiki = page in GitHub could be very useful for other edk2 developers.=20 >>From code change impact view, I see to use the hidden visibility for LTO, w= hich is to remove the !defined(USING_LTO) in X64/ProcessorBind.h actually, = need to change other 20+ files overall the edk2. The cost looks not small. = We might need more justification to accept such change. Does the hidden vi= sibility in LTO can improve the LTO build code size? Is there any other ben= efit? Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Tuesday, June 12, 2018 11:23 PM > To: edk2-devel@lists.01.org > Cc: Ard Biesheuvel ; Kinney, Michael D > ; Gao, Liming ; Ni, > Ruiyu ; Wu, Hao A ; Leif > Lindholm ; Justen, Jordan L > ; Andrew Fish ; Zeng, Star > ; Dong, Eric ; Laszlo Ersek > ; Zenith432 ; Shi, > Steven > Subject: [RFC PATCH 00/11] GCC/X64: use hidden visibility for LTO PIE cod= e >=20 > 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. >=20 > 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 (whi= ch > makes sense for PIC but not for PIE, but this simply seems to be the resu= lt > 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. >=20 > 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 direc= t > relative references rather than relative references to a GOT entry contai= ning > the absolute address. Unsurprisingly, this leads to better and smaller co= de. >=20 > 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. >=20 > 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= . >=20 > Note that all the changes in this series resolve to no-ops if USING_LTO > is not #defined. >=20 > Code can be found here: > https://github.com/ardbiesheuvel/edk2/tree/x64-lto-visibility >=20 > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Ruiyu Ni > Cc: Hao Wu > Cc: Leif Lindholm > Cc: Jordan Justen > Cc: Andrew Fish > Cc: Star Zeng > Cc: Eric Dong > Cc: Laszlo Ersek > Cc: Zenith432 > Cc: "Shi, Steven" >=20 > 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 >=20 > 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(-) >=20 > -- > 2.17.1