From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 0AA2121BC6ADB for ; Mon, 27 Mar 2017 08:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490628943; x=1522164943; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TYQeAVK14VQtOz2bTTILUrmdswMpiEhSFMRSyLdiO7Y=; b=kR8nzrvqh4hbMZDQjdQVCghkVsrYX6/TvZKlbcaHuv9VNmmLJzYT2Cxy 1NnNE1uZX6tEN//I6dgMr3CQzIhkdA==; Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 08:35:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,232,1486454400"; d="scan'208";a="1147486394" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga002.fm.intel.com with ESMTP; 27 Mar 2017 08:35:27 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.59]) by ORSMSX105.amr.corp.intel.com ([169.254.2.29]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 08:35:26 -0700 From: "Kinney, Michael D" To: Felix Poludov , "Gao, Liming" , "edk2-devel@lists.01.org" , "Kinney, Michael D" Thread-Topic: [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined symbols, and MSFT/GCC tool chains. Thread-Index: AdKkmm2mcThMLZckRnawazzXsHkPjwCDpsPAABg95DAAATdlkA== Date: Mon, 27 Mar 2017 15:35:25 +0000 Message-ID: References: <9333E191E0D52B4999CE63A99BA663A002DEEEDA95@atlms1.us.megatrends.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D702B8A@shsmsx102.ccr.corp.intel.com> <9333E191E0D52B4999CE63A99BA663A002DEEF126B@atlms1.us.megatrends.com> In-Reply-To: <9333E191E0D52B4999CE63A99BA663A002DEEF126B@atlms1.us.megatrends.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDYzNzdjNmYtZTcwNi00OGZhLWIxMTAtNTQ0NWNjOGM1ZjYzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjBoanpobXIxdmwxWW5WUm5hK0QrR1ZBZkxwNkxNRG4yY0luQW9vOGF2RUU9In0= x-originating-ip: [10.22.254.139] MIME-Version: 1.0 Subject: Re: [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined symbols, and MSFT/GCC tool chains. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 15:35:43 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Felix, I prefer the default policy to break the build if multiple defined symbols = are detected. Exceptions should only be allowed to support a specific compiler or a speci= fic level of compiler optimizations. I do like the addition of the /Gw switch to the newer VS compilers. Adding= the current GLOBAL_REMOVE_IF_UNREFERENCED macro to global variable declarations is a ma= nual process that usually requires inspection of PE/COFF images to notice that data that= should have been optimized away is still present. Adding the #ifndef also looks like a good way to adopt the /Gw switch in ne= wer VS=20 Compilers and preserve backwards compatibility with older VS compilers. Thanks, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Fe= lix Poludov > Sent: Monday, March 27, 2017 7:59 AM > To: Gao, Liming ; edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined= symbols, and > MSFT/GCC tool chains. >=20 > Liming, >=20 > Yes surrounding GLOBAL_REMOVE_IF_UNREFERENCED with #ifndef would be an im= provement. > Can you make this change? >=20 > On the other note, don't you think that EDKII should have a generic polic= y regarding > multiply defined symbols (whether they are allowed or not)? > Today, they may or may not work depending on the compiler used. >=20 > -----Original Message----- > From: Gao, Liming [mailto:liming.gao@intel.com] > Sent: Monday, March 27, 2017 12:49 AM > To: Felix Poludov; edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: RE: [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined symbol= s, and > MSFT/GCC tool chains. >=20 > Felix: > This changes the default MSFT build behavior. It will impact all platfo= rms even if > this platform has no requirement to pass GCC build. I suggest to update p= latform DSC > to enable it in MSFT tool chain if this platform needs to support MSFT an= d GCC both. >=20 > In Base.h: I agree to define GLOBAL_REMOVE_IF_UNREFERENCED only when it i= s not > defined. Then, Platform.dsc can append compiler option /D GLOBAL_REMOVE_I= F_UNREFERE to > the different value in [BuildOptions] section. >=20 > #ifndef GLOBAL_REMOVE_IF_UNREFERENCED > #define GLOBAL_REMOVE_IF_UNREFERENCED __declspec(selectany) > #endif >=20 > Thanks > Liming > >-----Original Message----- > >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > >Felix Poludov > >Sent: Friday, March 24, 2017 8:53 PM > >To: edk2-devel@lists.01.org > >Subject: [edk2] [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined > >symbols, and MSFT/GCC tool chains. > > > >Trying to add GCC support to projects based on MSFT tool chain, I'm keep > >stumbling into multiply defined symbol errors reported by GCC linker. > >An attempt to understand why the errors are not reported by the Microsof= t > >linker lead me to GLOBAL_REMOVE_IF_UNREFERENCED macro. > >The purpose of the macro is to enable link time optimization of global > >variables. > >However, the way it's defined for MSFT tool chain (__declspec(selectany)= ) > >has a side effect of explicitly allowing multiple instances of a symbol = defined > >with GLOBAL_REMOVE_IF_UNREFERENCED. > >For a while usage of the macro was the only option to enable global vari= able > >optimization. > >Starting from VS2013 compiler supports /Gw flag that enables global vari= able > >optimization without a special declarator. > > > >I propose to make the following modifications: > > > >1. Change GLOBAL_REMOVE_IF_UNREFERENCED definition to an empty > >macro. > > > >Or more specifically, update macro definition in Base.h as follows: > > > >#ifndef GLOBAL_REMOVE_IF_UNREFERENCED > > > >#define GLOBAL_REMOVE_IF_UNREFERENCED > > > >#endif > > > >2. Update VS2013 and VS2015 compiler flags to add /Gw option > > > >3. Update compiler flags for older MSFT tool chains to define > >GLOBAL_REMOVE_IF_UNREFERENCED in a backward compatible manner for > >targets that enable optimization. > > > >/D GLOBAL_REMOVE_IF_UNREFERENCED =3D_declspec(selectany) > > > > > >The advantages of these modifications are: > > > >- Better detection of on potential errors by breaking the build w= hen > >symbol is defined more than once. > > > >- Improved consistency between MSFT and GCC tool chains > > > >- Improved link time optimization with VS2013 and newer MSFT tool= chains. > > > >For example, mGaugeData in > >MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c > >is not declared as GLOBAL_REMOVE_IF_UNREFERENCED, so > > > >today performance library is linked with DXE Core even when performance > >measurements are disabled. > > > >The alternative option is to enable support of multiply defined symbols = on > >GCC tool chain. > >One way to do it is by defining the macro as > >#define GLOBAL_REMOVE_IF_UNREFERENCED __attribute__((weak)) > > > >However, I'm not sure that embracing multiple symbol definitions is a go= od > >idea. > >For example, see Ard's arguments in this commit comment > >https://github.com/tianocore/edk2/commit/214a3b79417f64bf2faae74af42c1 > >b9d23f50dc8 > > > >Thanks > >Felix > > > >Please consider the environment before printing this email. > > > >The information contained in this message may be confidential and > >proprietary to American Megatrends, Inc. This communication is intended= to > >be read only by the individual or entity to whom it is addressed or by t= heir > >designee. If the reader of this message is not the intended recipient, y= ou are > >on notice that any distribution of this message, in any form, is strictl= y > >prohibited. Please promptly notify the sender by reply e-mail or by tel= ephone > >at 770-246-8600, and then delete or destroy all copies of the transmissi= on. > >_______________________________________________ > >edk2-devel mailing list > >edk2-devel@lists.01.org > >https://lists.01.org/mailman/listinfo/edk2-devel >=20 > Please consider the environment before printing this email. >=20 > The information contained in this message may be confidential and proprie= tary to > American Megatrends, Inc. This communication is intended to be read only= by the > individual or entity to whom it is addressed or by their designee. If the= reader of > this message is not the intended recipient, you are on notice that any di= stribution of > this message, in any form, is strictly prohibited. Please promptly notif= y the sender > by reply e-mail or by telephone at 770-246-8600, and then delete or destr= oy all copies > of the transmission. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel