From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 3237C21A18AAA for ; Mon, 27 Mar 2017 23:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490680856; x=1522216856; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FJrBfUpF1U0fk485gHpyMPdUBNsNDi6R8Uv5hthUhvs=; b=t6LE4Oyz7PRr6eLDUCwr6SQrIjvwOFRDJuUJwHPasZE3VNuRp8ESBmLU 0sI6mF2RJDROnkhUOtnSdwN/fhxdgQ==; Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 23:00:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,235,1486454400"; d="scan'208";a="80036306" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by orsmga005.jf.intel.com with ESMTP; 27 Mar 2017 23:00:55 -0700 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 27 Mar 2017 23:00:55 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.59]) by ORSMSX152.amr.corp.intel.com ([169.254.8.130]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 23:00:54 -0700 From: "Kinney, Michael D" To: "Gao, Liming" , Felix Poludov , "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: AdKkmm2mcThMLZckRnawazzXsHkPjwCDpsPAABg95DAAATdlkAAApmqAAACEyBAAAErC0AABt9zgABZ5ngAABL9FcA== Date: Tue, 28 Mar 2017 06:00:54 +0000 Message-ID: References: <9333E191E0D52B4999CE63A99BA663A002DEEEDA95@atlms1.us.megatrends.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D702B8A@shsmsx102.ccr.corp.intel.com> <9333E191E0D52B4999CE63A99BA663A002DEEF126B@atlms1.us.megatrends.com> <9333E191E0D52B4999CE63A99BA663A002DEEF1308@atlms1.us.megatrends.com> <9333E191E0D52B4999CE63A99BA663A002DEEF136D@atlms1.us.megatrends.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14D704414@shsmsx102.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14D704414@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNThkMzk3NTAtYjFlNS00YWI4LTg4MzMtZDY2ZjdmOGMyODlkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImVuQmhaWWxSWjI4KzJOUittUENcL0xEbFB4TzlKeU9Ualp3RGFJd1E3WlRFPSJ9 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: Tue, 28 Mar 2017 06:00:56 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Liming, I agree that would work, but I would recommend the issue be fixed in the sources to avoid use of multiple defined symbols. Mike > -----Original Message----- > From: Gao, Liming > Sent: Monday, March 27, 2017 10:01 PM > To: Kinney, Michael D ; Felix Poludov ; > edk2-devel@lists.01.org > Subject: RE: [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined symbol= s, and > MSFT/GCC tool chains. >=20 > If platform decides not to fix them in platform code, they can redefine /= D > GLOBAL_REMOVE_IF_UNREFERENCED =3D_declspec(selectany) in [BuildOptions] s= ection of > Platform.dsc. >=20 > Thanks > Liming > > -----Original Message----- > > From: Kinney, Michael D > > Sent: Tuesday, March 28, 2017 1:07 AM > > To: Felix Poludov ; Gao, Liming ;= edk2- > devel@lists.01.org; Kinney, Michael D > > > > Subject: RE: [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined symb= ols, and > MSFT/GCC tool chains. > > > > Felix, > > > > We need to find all instances of that usage and fix them. > > > > We can make sure this issue is fixed for all open source packages > > and open source platforms before this change is committed to master. > > > > I recommend you generate a new version of the patch based on feedback > > from this thread and ask all package and platform owners to verify that > > their packages and platforms build with that change. > > > > Perhaps give 1-2 weeks for verification so the package and platform > > owners can resolve any issues found. > > > > Other opinions? > > > > Thanks, > > > > Mike > > > > > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf O= f Felix > Poludov > > > Sent: Monday, March 27, 2017 9:17 AM > > > To: Kinney, Michael D ; Gao, Liming > > > ; edk2-devel@lists.01.org > > > Subject: Re: [edk2] [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply def= ined symbols, > and > > > MSFT/GCC tool chains. > > > > > > Mike, > > > > > > I completely agree. > > > As far as code that breaks, the most typical problem I've seen is var= iable or > constant > > > defined in a header file included by more than one C file. > > > > > > Are you going to make these modifications or do you want me to submit= a patch? > > > > > > -----Original Message----- > > > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > > > Sent: Monday, March 27, 2017 12:07 PM > > > To: Felix Poludov; Gao, Liming; edk2-devel@lists.01.org; Kinney, Mich= ael D > > > Subject: RE: [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined sy= mbols, and > > > MSFT/GCC tool chains. > > > > > > Felix, > > > > > > What is the condition that will fail if /Gw is set and > GLOBAL_REMOVE_IF_UNREFERENCED > > > is defined to nothing? > > > > > > If these are real bugs, then I think we should identify those bugs an= d fix them > and > > > then apply this strong policy for newer VS compilers. > > > > > > Mike > > > > > > > -----Original Message----- > > > > From: Felix Poludov [mailto:Felixp@ami.com] > > > > Sent: Monday, March 27, 2017 8:59 AM > > > > To: Kinney, Michael D ; Gao, Liming > > > > ; edk2-devel@lists.01.org > > > > Subject: RE: [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined > > > > symbols, and MSFT/GCC tool chains. > > > > > > > > Mike, > > > > > > > > What do you think about defining GLOBAL_REMOVE_IF_UNREFERENCED in t= he > > > > tool chain definition file as an empty macro for a newer VS compile= rs? > > > > If this is done, as Liming pointed out, some code that compiles tod= ay may break. > > > > If this is not done, variables declared with > > > > GLOBAL_REMOVE_IF_UNREFERENCED are not subject to the default policy= of > > > > breaking the build if multiple defined symbols are detected when MS= FT tool chain > is > > > used. > > > > > > > > -----Original Message----- > > > > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > > > > Sent: Monday, March 27, 2017 11:35 AM > > > > To: Felix Poludov; Gao, Liming; edk2-devel@lists.01.org; Kinney, > > > > Michael D > > > > Subject: RE: [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined > > > > symbols, and MSFT/GCC tool chains. > > > > > > > > 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 > > > > specific 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 manual process that usually requires > > > > inspection of PE/COFF images to notice that data that should have b= een optimized > > > away is still present. > > > > > > > > Adding the #ifndef also looks like a good way to adopt the /Gw swit= ch > > > > in newer VS Compilers and preserve backwards compatibility with old= er VS > compilers. > > > > > > > > Thanks, > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Beha= lf > > > > > Of Felix 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. > > > > > > > > > > Liming, > > > > > > > > > > Yes surrounding GLOBAL_REMOVE_IF_UNREFERENCED with #ifndef would = be an > > > improvement. > > > > > Can you make this change? > > > > > > > > > > On the other note, don't you think that EDKII should have a gener= ic > > > > > policy regarding multiply defined symbols (whether they are allow= ed or not)? > > > > > Today, they may or may not work depending on the compiler used. > > > > > > > > > > -----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 define= d > > > > > symbols, and MSFT/GCC tool chains. > > > > > > > > > > Felix: > > > > > This changes the default MSFT build behavior. It will impact al= l > > > > > platforms even if this platform has no requirement to pass GCC bu= ild. > > > > > I suggest to update platform DSC to enable it in MSFT tool chain = if > > > > > this platform > > > > needs to support MSFT and GCC both. > > > > > > > > > > In Base.h: I agree to define GLOBAL_REMOVE_IF_UNREFERENCED only w= hen > > > > > it is not defined. Then, Platform.dsc can append compiler option = /D > > > > > GLOBAL_REMOVE_IF_UNREFERE to the different value in [BuildOptions= ] section. > > > > > > > > > > #ifndef GLOBAL_REMOVE_IF_UNREFERENCED > > > > > #define GLOBAL_REMOVE_IF_UNREFERENCED __declspec(selectany) #en= dif > > > > > > > > > > Thanks > > > > > Liming > > > > > >-----Original Message----- > > > > > >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Beh= alf > > > > > >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 G= CC linker. > > > > > >An attempt to understand why the errors are not reported by the > > > > > >Microsoft 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 allowin= g > > > > > >multiple instances of a symbol defined with GLOBAL_REMOVE_IF_UNR= EFERENCED. > > > > > >For a while usage of the macro was the only option to enable glo= bal > > > > > >variable optimization. > > > > > >Starting from VS2013 compiler supports /Gw flag that enables glo= bal > > > > > >variable optimization without a special declarator. > > > > > > > > > > > >I propose to make the following modifications: > > > > > > > > > > > >1. Change GLOBAL_REMOVE_IF_UNREFERENCED definition to an em= pty > > > > > >macro. > > > > > > > > > > > >Or more specifically, update macro definition in Base.h as follo= ws: > > > > > > > > > > > >#ifndef GLOBAL_REMOVE_IF_UNREFERENCED > > > > > > > > > > > >#define GLOBAL_REMOVE_IF_UNREFERENCED > > > > > > > > > > > >#endif > > > > > > > > > > > >2. Update VS2013 and VS2015 compiler flags to add /Gw optio= n > > > > > > > > > > > >3. Update compiler flags for older MSFT tool chains to defi= ne > > > > > >GLOBAL_REMOVE_IF_UNREFERENCED in a backward compatible manner fo= r > > > > > >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 when > > > > > >symbol is defined more than once. > > > > > > > > > > > >- Improved consistency between MSFT and GCC tool chains > > > > > > > > > > > >- Improved link time optimization with VS2013 and newer M= SFT 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 good idea. > > > > > >For example, see Ard's arguments in this commit comment > > > > > >https://github.com/tianocore/edk2/commit/214a3b79417f64bf2faae74= af4 > > > > > >2c > > > > > >1 > > > > > >b9d23f50dc8 > > > > > > > > > > > >Thanks > > > > > >Felix > > > > > > > > > > > >Please consider the environment before printing this email. > > > > > > > > > > > >The information contained in this message may be confidential an= d > > > > > >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 their designee. If the reader of this message is > > > > > >not the intended recipient, you are on notice that any distribut= ion > > > > > >of this message, in any form, is strictly prohibited. Please > > > > > >promptly notify the sender by reply e-mail or by telephone at > > > > > >770-246-8600, and then delete > > > > or destroy all copies of the transmission. > > > > > >_______________________________________________ > > > > > >edk2-devel mailing list > > > > > >edk2-devel@lists.01.org > > > > > >https://lists.01.org/mailman/listinfo/edk2-devel > > > > > > > > > > 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 i= s > > > > > addressed or by their designee. If the reader of this message is = not > > > > > the intended recipient, you are on notice that any distribution o= f > > > > > this message, in any form, is strictly prohibited. Please prompt= ly > > > > > notify the sender by reply e-mail or by telephone at 770-246-8600= , > > > > > and then delete > > > > or destroy all copies of the transmission. > > > > > _______________________________________________ > > > > > edk2-devel mailing list > > > > > edk2-devel@lists.01.org > > > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > > > > > 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 their designee. If the reader of this message is no= t > > > > the intended recipient, you are on notice that any distribution of > > > > this message, in any form, is strictly prohibited. Please promptly > > > > notify the sender by reply e-mail or by telephone at 770-246-8600, = and then > delete > > > or destroy all copies of the transmission. > > > > > > Please consider the environment before printing this email. > > > > > > The information contained in this message may be confidential and pro= prietary 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 an= y > distribution of > > > this message, in any form, is strictly prohibited. Please promptly n= otify the > sender > > > by reply e-mail or by telephone at 770-246-8600, and then delete or d= estroy all > copies > > > of the transmission. > > > _______________________________________________ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel