From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.35; helo=mail-in25.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (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 BC3502096DCF7 for ; Fri, 18 May 2018 16:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1526684833; x=2390598433; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=E/JfXM8XGK/qDcvctiRGDXQ57RDxQXT9uvtBA0hoL70=; b=a/ji8w3sUhQEHeXmmHE/P1QUbtbAhK/7sj+DjeUMPvKkxPzqSFf9BGge6JtL78Ei jzytuDvNVP3HT5HfCAuab4OT9vIW+ESFQ9iE9Qxydv1aj6MU/YP4QOhv5kttjFO3 Y44Zk3qc9ce2T0sLG6LGGo0/n9F7TmzfS4V8qiEHWzxfHV+zxJQND0zYeXjHXMHF s3ZzSSp/0j1aN5pkOI44Njsw9/kYIyDnwtn8WWCVW1t+4Ck/iUhL4IJp8tZczAub 6OEs+qgDf6LOzZZacbDUAIt3I6XeYhu/u+CJXyjiVh1RypsXULGad2z511f05/NH mmWIr04NzKTMCk3AzC30Mg==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id E5.64.14365.1AC5FFA5; Fri, 18 May 2018 16:07:13 -0700 (PDT) X-AuditID: 11ab0219-e904d9e00000381d-5c-5aff5ca14b78 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 31.11.11536.0AC5FFA5; Fri, 18 May 2018 16:07:13 -0700 (PDT) MIME-version: 1.0 Received: from [17.235.32.23] (unknown [17.235.32.23]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P8Y0029Z5JZLT00@nwk-mmpp-sz12.apple.com>; Fri, 18 May 2018 16:07:12 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <0E83E7B9-AA12-4921-A7A2-ABA9DBD8D2AA@apple.com> Date: Fri, 18 May 2018 16:07:10 -0700 In-reply-to: <040701d3eef9$95563a80$c002af80$@insyde.com> Cc: edk2-devel@lists.01.org To: Tim Lewis References: <03b101d3eef6$a5f4dd90$f1de98b0$@insyde.com> <01146E3B-6B4F-4C58-B753-63BFD5ADF3E4@apple.com> <040701d3eef9$95563a80$c002af80$@insyde.com> X-Mailer: Apple Mail (2.3445.6.18) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUi2FAYrrsw5n+UwdGN2hZ7Dh1ltrj4YxWT A5NH+5v/bB7ds/+xBDBFcdmkpOZklqUW6dslcGWcubiTuWD9JZaKtq0zmBoYn3axdDFyckgI mEgcedPGBmILCaxhkjg0hR8m/nfCTeYuRi6g+AYmib5dCxhBErwCghI/Jt8Da2YWCJP4fWc+ C0RRP5PEwr2dTCAJYQFxiXdnNjGD2GwCyhIr5n9gh2i2kehYsocFosZHYtXmZqAaDg4WAVWJ hkvhIGFOAUuJbStmskPMl5Z4OPE4K4gtIqAi0TpxJTvErlmMEo37b7NBXKok8X/XEbBLJQQW sEl0/JvNPoFRaBaSY2chORbC1pL4/qgVyOYAsuUlDp6XhQhrSjy794kdwtaWePLuAusCRrZV jMK5iZk5upl5RqZ6iQUFOal6yfm5mxhBEbGaSXIH49fXhocYBTgYlXh4E+78ixJiTSwrrsw9 xCjNwaIkzvuZ7VGUkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaN6Tb+avWPr97ma7OOY9pm PXG32qxN82YW9zkqnmFdc76fs+qHXrjlg91rP6/suVpnO5MveoJBwuSl/gsV2cM6N/lFiwl3 zPNa0Hf0tKJJRVub3t34exu6PNuqC7+YZmRIqs8oEeL7max49WvwzCsr7nTy3Z+5bebM31fc lK4o7Py5ft6CiYeVWIozEg21mIuKEwHYhseGaQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUi2FB8RndhzP8og/bpTBZ7Dh1ltrj4YxWT A5NH+5v/bB7ds/+xBDBFcdmkpOZklqUW6dslcGWcubiTuWD9JZaKtq0zmBoYn3axdDFyckgI mEj8nXCTuYuRi0NIYAOTRN+uBYwgCV4BQYkfk++BFTELhEn8vjOfBaKon0li4d5OJpCEsIC4 xLszm5hBbDYBZYkV8z+wQzTbSHQs2cMCUeMjsWpzM1ANBweLgKpEw6VwkDCngKXEthUz2SHm S0s8nHicFcQWEVCRaJ24kh1i1yxGicb9t9kgLlWS+L/rCPMERv5ZSO6bheQ+CFtL4vujViCb A8iWlzh4XhYirCnx7N4ndghbW+LJuwusCxjZVjEKFKXmJFaa6CUWFOSk6iXn525iBAdwYfgO xn/LrA4xCnAwKvHwctz6FyXEmlhWXJl7iFGCg1lJhDfT4n+UEG9KYmVValF+fFFpTmrxIUZp DhYlcV5eIaBqgfTEktTs1NSC1CKYLBMHp1QD4zZ5Q6PcCBnj7pz1c6VqDVPPzbgzM/PE97ZX Ni2T6hR3aVedvLtOVVX8yxLFqB1r+PnsWS9JLCm4zPc/Z8KsN44ZkjlhP3Y/0s+7J1d+6rv9 7OgjVjX7Hk9U/ndkllM1U9TGmQvXmRjabov4eH/3m65ey77F0SsV1Z96dUREPqkQnjArXSX1 hBJLcUaioRZzUXEiAAgKDztcAgAA X-Content-Filtered-By: Mailman/MimeDel 2.1.26 Subject: Re: Does __attribute__ ((selectany)) make sense now for GCC? 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: Fri, 18 May 2018 23:07:15 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Tim, VC++ is a strange beast. See C99 support. VC++ seems to do strange things to support non standard hackyness of years past. So the only reason I can think of that __attribute__ ((selectany)) is associated with dead stripping, is doing it correctly broke some chunk of code that was required for compatibility. From looking on the VC++ site it seems like COMDAT folding may be required for dead code removal, but again this not required to make it work, but to not break old crufty stuff. I guess on Windows GCC they could trying to "copy exact" VC++ behavior, but it is most definitely going to be ignored on the non-Windows versions. The answer from Microsoft on C99 is to use clang :) Thanks, Andrew Fish > On May 18, 2018, at 3:43 PM, Tim Lewis wrote: > > Andrew - > > > > I know for Visual Studio it does the same thing for data that /Gy does for > code. > > > > That is, if the data is unreferenced, then it doesn't get brought it. > > > > Maybe link-time code generation has the same effect. That's what I'm curious > about. > > > > Tim > > > > From: afish@apple.com > > Sent: Friday, May 18, 2018 3:39 PM > To: Tim Lewis > > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC? > > > > Tim, > > > > Looks like that is only available on Windows versions of GCC, and is more > about compatible behavior. > > > > selectany > > The selectany attribute causes an initialized global variable to have > link-once semantics. When multiple definitions of the variable are > encountered by the linker, the first is selected and the remainder are > discarded. Following usage by the Microsoft compiler, the linker is told not > to warn about size or content differences of the multiple definitions. > > Although the primary usage of this attribute is for POD types, the attribute > can also be applied to global C++ objects that are initialized by a > constructor. In this case, the static initialization and destruction code > for the object is emitted in each translation defining the object, but the > calls to the constructor and destructor are protected by a link-once guard > variable. > > The selectany attribute is only available on Microsoft Windows targets. You > can use __declspec (selectany) as a synonym for __attribute__ ((selectany)) > for compatibility with other compilers. > > > > What I've noticed with clang/LLVM is the unreferenced globals get removed > when you enable link time optimizations. > > > > I'd actually ask the opposite question. Does __declspec(selectany) impact > dead code removal on current versions of VC++? > > > > Thanks, > > > > Andrew Fish > > > > > > On May 18, 2018, at 3:22 PM, Tim Lewis > > wrote: > > > > In Visual Studio we have __declspec(selectany) to limit the impact of unused > data. > > > > I see that GCC for Windows has __attribute__ ((selectany)). > > > > Should we me using this for GLOBAL_REMOVE_IF_UNREFERENCED in > MdePkg\Include\Base.h? > > > > Tim > > _______________________________________________ > edk2-devel mailing list > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel