From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from atlmailgw1.ami.com (atlmailgw1.ami.com [63.147.10.40]) (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 0A64280406 for ; Fri, 24 Mar 2017 05:53:52 -0700 (PDT) X-AuditID: ac1060b2-a5bff70000000c96-ac-58d516ca554c Received: from atlms2.us.megatrends.com (atlms2.us.megatrends.com [172.16.96.152]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 05.88.03222.AC615D85; Fri, 24 Mar 2017 08:53:31 -0400 (EDT) Received: from ATLMS1.us.megatrends.com ([fe80::8c55:daf0:ef05:5605]) by atlms2.us.megatrends.com ([fe80::29dc:a91e:ea0c:cdeb%12]) with mapi id 14.03.0123.003; Fri, 24 Mar 2017 08:53:29 -0400 From: Felix Poludov To: "edk2-devel@lists.01.org" Thread-Topic: [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined symbols, and MSFT/GCC tool chains. Thread-Index: AdKkmm2mcThMLZckRnawazzXsHkPjw== Date: Fri, 24 Mar 2017 12:53:29 +0000 Message-ID: <9333E191E0D52B4999CE63A99BA663A002DEEEDA95@atlms1.us.megatrends.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.99.93] MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42JZI5AwQ/eK2NUIgwNbLC32HDrK7MDo0T37 H0sAY1QDo01iXl5+SWJJqkJKanGyrVJAUWZZYnKlkkJmiq2SoZJCQU5icmpual6JrVJiQUFq XoqSHZcCBrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1VLILyUhVyMxLyy/KTSzJzM9TSM7P KwGqTk0BiiokdHFmzFr5hbGgJ6fiz/cnLA2MzfFdjJwcEgImEudf3WXsYuTiEBKYzSTRc3Mj O4RzmFHizI9/bCBVbAIqEpvOXmAGsUUEzCVa519hArGFBZIlzm46wgoRz5B4eeocVI2eRN+i c0BTOThYBFQl7q20AzF5BQIlztywBalgFBCT+H5qDdgUZgFxiVtP5jNB3CMgsWTPeWYIW1Ti 5eN/rBC2gsSW953sEPX5EjOXLgSL8woISpyc+YRlAqPgLCSjZiEpm4WkDCKuI7Fg9yc2CFtb YtnC18ww9pkDj5mQxRcwsq9iFEosyclNzMxJLzfUS8zN1EvOz93ECInxTTsYWy6aH2IU4GBU 4uE9yHg1Qog1say4MvcQowQHs5IIb6gIUIg3JbGyKrUoP76oNCe1+BCjEzBQJjJLcYNiCBjl 8cYGBlKiMI6hiZmJuZG5oaWJubGxkjhvCdP+CCGBdGDSyU5NLUgtghnCxMEp1cDIvSmg5uN3 maubetjvBCUqmi6fvrtZ75ZnrfImu2Wng16oGZmdnZkjFN16Z3rCxvLWyAXZH1N1W4W0RBo6 3j5u6/37dHX7Kqejr4884DGxPjblecPb0EeZ3SKlMdKm/lnCJs3vL/NtLnuzR6LsnEeu0sL/ Z88ekeh4HWocVlCTV71y0cziW5JKLMUZiYZazEXFiQBODOP+FAMAAA== X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: [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: Fri, 24 Mar 2017 12:53:53 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trying to add GCC support to projects based on MSFT tool chain, I'm keep stu= mbling into multiply defined symbol errors reported by GCC linker. An attempt to understand why the errors are not reported by the Microsoft li= nker lead me to GLOBAL_REMOVE_IF_UNREFERENCED macro. The purpose of the macro is to enable link time optimization of global varia= bles. However, the way it's defined for MSFT tool chain (__declspec(selectany) ) h= as a side effect of explicitly allowing multiple instances of a symbol defin= ed with GLOBAL_REMOVE_IF_UNREFERENCED. For a while usage of the macro was the only option to enable global variable= optimization. Starting from VS2013 compiler supports /Gw flag that enables global variable= 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_RE= MOVE_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 when= symbol is defined more than once. - Improved consistency between MSFT and GCC tool chains - Improved link time optimization with VS2013 and newer MSFT tool cha= ins. For example, mGaugeData in MdeModulePkg/Library/DxeCorePerformanceLib/DxeCor= ePerformanceLib.c is not declared as GLOBAL_REMOVE_IF_UNREFERENCED, so today performance library is linked with DXE Core even when performance meas= urements are disabled. The alternative option is to enable support of multiply defined symbols on G= CC 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 i= dea. For example, see Ard's arguments in this commit comment https://github.com/tianocore/edk2/commit/214a3b79417f64bf2faae74af42c1b9d23f= 50dc8 Thanks Felix Please consider the environment before printing this email. The information contained in this message may be confidential and proprietar= y to American Megatrends, Inc. This communication is intended to be read on= ly 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 not= ice that any distribution of this message, in any form, is strictly prohibit= ed. Please promptly notify the sender by reply e-mail or by telephone at 77= 0-246-8600, and then delete or destroy all copies of the transmission.