From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 54112802E6 for ; Fri, 24 Mar 2017 10:32:12 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id y18so8072011itc.1 for ; Fri, 24 Mar 2017 10:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HxGzuhePoI3K4fm9bwAZl5q4g96C9egiU/dBXQ7l8Ow=; b=htoiatw9xxNi76R2oCD/or4PtSl7NomJyjYnb76NVsmDOL7C22pZ+Xbzub2XEcORIS t4GZXIVSX8hC5bodRvmBFHTdxigJk/ge3NvISBuY58W+1sMxJh11df1VTAn9X8rM7tml FoUKUrmtF/DqtlWXVnTvIoMvcB4yOAibMzrQ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HxGzuhePoI3K4fm9bwAZl5q4g96C9egiU/dBXQ7l8Ow=; b=V0o3T4+qiVEpualw5/BG0tnLwc1SfBGhfoxZDz/Eg3jGQxDAvlVOWLPJK4OneR3gCc gIpqjwFnI718IC5mCd2+cJHMsnBEwwL2NvsLO853o2cmsKpyYX6TwnMjM393+W34cCS7 jHmZzvPxZ5kKX/nZd+XDtqP7iOOifGWAqhqV/0YRrZnUWcoV8z2KZyzFfS7JrfG5GaFu qWSM0mwHR2OYLhpJ7jJoz5wNramwVnBf93AbI8KSd3NzBvqs2ODZkRhqqiyKcuqxeyxD E7GQ0mW81hQeGwbUUxFjXEE4h38tQo+qMDmw8WmCuj6T7Na7K1TNzZnue/vd3aTqRNma XE+g== X-Gm-Message-State: AFeK/H2zAt47f5vFRcAIQnBpowm/R47jyXt/Xw7+AdEfpMcGKOWwUB5M4v5mZ2l7+Kc78elQk93E9HjViLC2h/ni X-Received: by 10.36.207.212 with SMTP id y203mr4036766itf.63.1490376731589; Fri, 24 Mar 2017 10:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Fri, 24 Mar 2017 10:32:11 -0700 (PDT) In-Reply-To: <9333E191E0D52B4999CE63A99BA663A002DEEEDA95@atlms1.us.megatrends.com> References: <9333E191E0D52B4999CE63A99BA663A002DEEEDA95@atlms1.us.megatrends.com> From: Ard Biesheuvel Date: Fri, 24 Mar 2017 17:32:11 +0000 Message-ID: To: Felix Poludov Cc: "edk2-devel@lists.01.org" 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: Fri, 24 Mar 2017 17:32:12 -0000 Content-Type: text/plain; charset=UTF-8 On 24 March 2017 at 12:53, Felix Poludov wrote: > 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 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 allowing multiple instances of a symbol defined with GLOBAL_REMOVE_IF_UNREFERENCED. This smells like a variant of the GCC COMMON issue that you quote below. 'Select any' presumes that globally visible symbols with the same name are guaranteed to refer to the same data item, and the nature and architecture of EDK2 make it impossible to ever be sure about that (i.e., cross-package library class resolution) > 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_REMOVE_IF_UNREFERENCED in a backward compatible manner for targets that enable optimization. > > /D GLOBAL_REMOVE_IF_UNREFERENCED =_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 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)) > No! That may fix your build, but it only papers over the problem. > 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/214a3b79417f64bf2faae74af42c1b9d23f50dc8 > GCC used -ffunction-sections and -fdata-sections, and performs link time garbage collection (--gc-sections), and so globals that are never referenced will ultimately be dropped anyway. So in the mGaugeData case you mention above, GCC (or rather, GNU ld), should notice that no references to it exists, and the section containing just mGaugeData will be dropped from the build. As I mentioned in the commit log of the above patch, STATIC is the key here. In my opinion, STATIC should be mandatory for all function and variables that are only referenced from the same compilation unit. Not only does it help the compiler produce better code (in the absence of LTO), it prevents namespace pollution and generally results in better structured code (given that you can't easily link to some symbol in another object) Given that each of the linker errors you get points to a potential problem in your code, perhaps the best approach would be to temporarily define GLOBAL_REMOVE_IF_UNREFERENCED to STATIC instead, so you can track down the occurrences that really require external linkage, but have multiple definitions, and fix those up manually.