From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11095 invoked by alias); 15 Feb 2011 18:49:46 -0000 Received: (qmail 11084 invoked by uid 22791); 15 Feb 2011 18:49:46 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Feb 2011 18:49:41 +0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 15 Feb 2011 18:51:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-02/txt/msg01851.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #13 from Jan Hubicka 2011-02-15 18:49:15 UTC --- > A quick summary to see if got this right: Yes, the summary seems right. Note that GCC plays now games with not putting COMDATs into LTO symbol table unless they really need to be unique. So if you have simple inline functions with no address taken things the function is never put into LTO symbol table and linker doesn't care. GCC then merge the different copies itself and promote the function into static function. This worlsf well except for possibility of having two instances of the function (one in LTO world that is promoted to static function and one in non-LTO code staying as comdat). This works well for Firefox ;)) Things gets ugly with variables and stuff that has address taken. This is less common in C++ code but still worrysome. > On LLVM land I think this translates to > > *) If given PREVAILING_DEF, linkonce gets upgrade to weak and linkonce_odr to > weak_odr > *) If given PREVAILING_DEF_IRONLY_EXP, likages stay as they are > *) If given PREVAILING_DEF_IRONLY the symbol gets internalized > > I think this should work, thanks. I am not sure if you are allowed to change COMDAT into weak. The plugin spec explicitely speaks of comdat symbol staying and I am not sure if Gold/GNU ld are ready for symbol changing their type. Taking PREVAILING_DEF is silently accepted by both gold and GNU ld, but in gold it results in stale dynamic symbol table entries. GCC originally behaved on PREVAILING_DEF as if it was PREVAILING_DEF_IRONLY_EXP and it did result in massive dynamic symbol table section increases. Honza