From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16647 invoked by alias); 2 Dec 2010 01:03:54 -0000 Received: (qmail 16529 invoked by uid 22791); 2 Dec 2010 01:03:53 -0000 X-SWARE-Spam-Status: No, hits=-2.8 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; Thu, 02 Dec 2010 01:03:48 +0000 From: "davek at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: meta-bug X-Bugzilla-Severity: normal X-Bugzilla-Who: davek at gcc dot gnu.org 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: CC 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: Thu, 02 Dec 2010 01:03: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: 2010-12/txt/msg00117.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Dave Korn changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |davek at gcc dot gnu.org --- Comment #12 from Dave Korn 2010-12-02 01:03:43 UTC --- (In reply to comment #11) > OK, > working around the previous issues we fail with: > > /abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld: > gTLSIsMainThread: TLS reference in /tmp/cczRYvg1.ltrans0.ltrans.o mismatches > non-TLS definition in nsThreadManager.o.ironly section .text > > Dave, is this a GNU LD bug? It seems to me that most likely that > nsThreadManager.o.ironly section is the one got from lto plugin and we don't > put TLS annotations there because we have no way to do so? Yeh, precisely. The ironly file is a placeholder into which we put the symbols found in the lto symtab so that they can take part in the link and their resolutions be determined. We have no way of conveying any symbol type info. We'll need to handle this in the multiple-def linker hook in LD's plugin code, by getting it to copy type info from the newly-added symbols to the ironly ones. Oh, hang on, that won't work. elflink.c calls _bfd_elf_merge_symbol /before/ _bfd_generic_link_add_one_symbol, which is where the multiple-def hook gets called back from. So it'll error on the mismatch before we get a chance to do anything about it. That's awkward. Need to scratch my head over that for a bit.