[Bug ld/12323] New: linker plugin does not handle TLS

[jh at suse dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=12323

           Summary: linker plugin does not handle TLS
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
        AssignedTo: address@hidden
        ReportedBy: address@hidden


building mozilla with mainline GCC and GNU LD as linker 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

gold work.

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

(In reply to comment #13)
> >   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
> 
> The error comes out after the lto1 invocation, so why the ironly section is
> still around?
> I would expect it to be discarded at that time and replaced by whatever
> compiler
> returns to you.

  It's the symbol from the ironly section that remains, and it gets discarded
and replaced by the the symbol from the real object file by the linker
multiple_definition callback hook when _bfd_generic_link_add_one_symbol is
called to add the symbol from the real object file into the link hash table.

  Unfortunately, the elf linker has some additional checking that it does
before calling that routine which preemptively complains about the multiple
definition before the linker hook has a chance to replace the original ironly
symbol by the new one.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.