[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

["davek at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

Dave Korn <davek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu.org

--- Comment #12 from Dave Korn <davek at gcc dot gnu.org> 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.