From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.163.184.47; helo=sonic317-36.consmr.mail.ne1.yahoo.com; envelope-from=zenith432@users.sourceforge.net; receiver=edk2-devel@lists.01.org Received: from sonic317-36.consmr.mail.ne1.yahoo.com (sonic317-36.consmr.mail.ne1.yahoo.com [66.163.184.47]) (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 88FDB212B6D4D for ; Wed, 13 Jun 2018 01:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1528877051; bh=Cwmy5lGqH0pYcbsygWcjqKfPJITsTY7yRm3Woo9DpkQ=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=M3z1pSjmWuOOQPwhJw1k6SSsBSg9VrGm7HKHjuZuoniV0qUqQdt4aE4TXYFCnCI/ecFEAJiqsJgH8vU6bcRlh6Jt8qLkZ5Q1ftie5q2Iuad7Cc/oC4FJZ3jcilpD/G3dE1jrPdHxh+Eha4FF/9A1mhGuDUKoDNJhxk5uvcHAPSRzk4KbSIVQVhfTiLeRohBoK5X65rcgUqqwVcHHke4uSpPdy/fI831Bjk3O3nUc4kjJlmSSDinT6N7anV8XdxBeBtOIZceI6x46Q8ZwrlLAipYPmQLIWyV/RktuSVvNbo8F+4tcn8KGUCmvSU7fELQfvyVEo8CCmuiz8PIutWkW6A== X-YMail-OSG: GhSG3sAVM1mc_uMznod7Zj67_WleLyl9cSfwdiCVYc_FwrHYugScunglzsK10I5 1nFj7VvQPTAMp14tG0McZ.913PvtkBX2_kmSTVuFLRo5Cm9RxuJRu4dIs2bO9.cuZ7ISC3jI96m9 nMSbo5.If2pqNRNv67hd23coeUG7P8D_zx_P9TVVICvk0pKOXHzd7Gky4956ro6qU1B4GGQr0gTH vrUDW_jkqtiwGVeVbTTTB47LoNDe.3SZKlKGyfQv72s3ClU78bZRncIwK9X5uOk1IIa3oajHV_ZC 22SHxuiua4aEZrDrcys8b6faS.P2xKUo0hoZRMgD2UzolJ5YeypLzDXYHfmSlH3UGYteUj9IfBI3 bIn.50hkkImA.x6OVFN9kl7PgoXb6np1m.r1LSg9Co2wlR7CfobRnUTm5A0J_2paIJ75S4iaJNiU TB2TKuVop4SeMUA2_ZDOIuuDq92e3i3vPCGnTjeQj8XexkdPJkWVvpMdv8aD1dwk6HDeK2cs4xS5 O.IL0w63M5IMfqrC_YRY1IZ_EHYSgOFDgvY0l.yD2CViugChiq3a6kIYszbO7qa9Sjy91dUKSdNf 5Mqea33dlnp_mMG19KjU8PLw6DZilw2F9Et2tyVFBDjDwqGXExRsB_bQwSLXT2In9NMwa4fo4m.U lBt4HFbWS2aDf6Lh0V0owjGQX.cGohNtSRugsiAxlbHc1O.iqFDCUaIEa.l0CI0tlNYYS4V5ydY6 DjgrTjfpThcBJ77bWw4uAeaq8lN6aVI7uoujwOtQJnkvUiyZblY9z1z5Ol_UfRSmsAvZxgmByaSt qXz612mj3U2Lyrgfc1V1JuOjXGi8LK5eQcAoqaQA58Chamu9qmWch501ZOkbPSiFaF9tJqNDUIqo bXmnraCziHuVa6xlieri6OM7lx84aY9VLyaiPwoHFO2WJVcKej3Ma.O4xZTRIsnElEBvUXKPYO2X Xz6A- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Wed, 13 Jun 2018 08:04:11 +0000 Date: Wed, 13 Jun 2018 08:04:07 +0000 (UTC) From: Zenith432 Reply-To: Zenith432 To: StevenShi Cc: "edk2-devel@lists.01.org" Message-ID: <1971023844.4599916.1528877047633@mail.yahoo.com> MIME-Version: 1.0 References: <1971023844.4599916.1528877047633.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11950 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.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 08:04:12 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The size differences are negligible because the code generator only emits G= OT loads in narrow circumstances that reduce code size - using pointer arithmetic on an address of an external symbol. - if loading an address of an external symbol as function a argument using = a push instruction. Emitting GOT loads in these scenarios slightly reduces code size, but it fo= rces the emission of the referenced GOT entry into the executable as well.= =C2=A0 If no GOT entries are referenced by the code, they are discarded by = the linker gc-sections feature.=C2=A0 When GOT entries are referenced from = the code, they also get emitted.=C2=A0 So it's a tradeoff - if many GOT loa= ds reference the same symbol - size is reduced.=C2=A0 If only one or two GO= T loads reference a symbol, size may grow. The number of such cases is also very small due to the narrow circumstances= of the optimization opportunities. In GCC49 toolchain with LTO off, there are no GOT loads today because of vi= sibility pragma. If visibility pragma is suppressed, I counted 6 cases in MdeModulePkg when = building OvmfPkgX64.dsc.=C2=A0 This is what originally broke the build and = caused the visibility pragma to be included. In GCC5, the circumstances of GOT-load emission is further narrowed by the = LTO.=C2=A0 It happens only when... - An external symbol is defined in assembly (so it remains external to LTO)= . - C code declares the external symbol and uses it in one of the narrow circ= umstances listed above where GOT loads reduce code size. That is what is demonstrated in the sample.=C2=A0 There are no such cases i= n EDK2 code base so GCC5 build doesn't break. The size differences being negligible - the only reason this is an issue is= that if a GOT load is emitted - it breaks the build since GenFw doesn't ha= ndle it. So one option is to just ignore this since it doesn't happen in today's cod= ebase, but since it can happen - document what the workarounds are: - one workaround is to manually declare external symbols that cause GOT loa= ds with __attribute__((visibility("hidden"))) - I've also found that using __attribute__((optimize("O2"))) on a function = that emits GOT loads sometimes eliminates the GOT load.=C2=A0 This is becau= se the GOT load is only emitted to reduce code size, so if changing optimiz= ation to speed - the GOT load is no longer used. Another option is what is suggested by Ard Biesheuvael to arrange things so= that all external symbols except module entry points are hidden. This res= olves the problem for GCC5 LTO build in the closest way similar to the reso= lution for GCC49 non-LTO build. Another option is to add functionality to GenFw for handling the various X6= 4 GOTPCREL emissions for the small number of cases that are expected to occ= ur. However, I cannot guarantee that future changes in the compiler will n= ot start emitting thousands of GOT loads and this goes unnoticed because Ge= nFw is handling them silently. This is an undesirable scenario. -------------------------------------------- On Wed, 6/13/18, Shi, Steven wrote: ... Does the hidden visibility in LTO can improve the LTO build code size? Is there any other benefit? =20 Steven Shi Intel\SSG\STO\UEFI Firmware =20