From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25659 invoked by alias); 15 Feb 2011 23:20:57 -0000 Received: (qmail 25649 invoked by uid 22791); 15 Feb 2011 23:20:56 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_LV 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 23:20:52 +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: Wed, 16 Feb 2011 00:23: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/msg01884.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 --- Comment #15 from Jan Hubicka 2011-02-15 23:20:40 UTC --- > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 > > --- Comment #14 from Rafael Avila de Espindola 2011-02-15 19:39:09 UTC --- > Sorry, can you expand on what gcc was doing that was causing it to expand the > dynamic symbol table? > > With LLVM what we are doing is > > *) Report all symbols > *) Any symbol not given a PREVAILING_DEF, we make it internal. > *) All other symbols stay the same. > > For example, a vtable is normally produce as a symbol with linkonce_odr (see The problem is with dropping linkonce_odr that has been previously reported. This way gold will allocate entry in the dynamic symbol table (you can see it in nm of the final binary) with no definition/use. Once something is given PREVAILING_DEF, it can not be optimized away. > We produce IL for a.cc and a ELF for b.cc. Gold decides to use the IL version, > gives the plugin a PREVAILING_DEF. LLVM optimises the use away and drops the > vtable. We now have an undefined reference to the vtable. Yes, that is problem, too, but I didn't see it in practice. > > With both PREVAILING_DEF_IRONLY_EXP and PREVAILING_DEF llvm would be able to > tell the difference. If there was no use of the vtable from an ELF file, gold > would give a PREVAILING_DEF_IRONLY_EXP and llvm would be allowed to drop it. If > there is, gold gives a PREVAILING_DEF and llvm must upgrade the vtable from > linkonce_odr to weak_odr which causes it to say in the final .o even if it > optimises out all uses. Yes, that seems right except that GCC makes difference in between comdat symbols that must stay even if they are optimized out and weak symbols since both are handled bit differently. I am not sure if updating comdat symbol to weak is safe in ELF world, probably Iant would know. Honza