Bug 12323 - linker plugin does not handle TLS
Summary: linker plugin does not handle TLS
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: H.J. Lu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-15 00:42 UTC by Jan Hubicka
Modified: 2016-05-16 18:31 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Hubicka 2010-12-15 00:42:54 UTC
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.
Comment 1 H.J. Lu 2010-12-17 22:10:52 UTC
Please try hjl/lto-mixed branch at

http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary

If it doesn't work, please provide a small testcase and
I will fix it.
Comment 2 H.J. Lu 2010-12-17 22:21:48 UTC
I think this has been fixed by 2 stage linking:

Stage 2 command line:
  /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbegin.o /tmp/ccdj7Ial.ltrans0.ltrans.o --no-whole-archive ./libbar.a --no-whole-archive /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/libgcc.a /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgcc_s.so /usr/lib/../lib64/libc.so --no-whole-archive /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/libgcc.a /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgcc_s.so /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtend.o /usr/lib/../lib64/crtn.o
exclude stage 1 input: /usr/lib/../lib64/crt1.o
exclude stage 1 input: /usr/lib/../lib64/crti.o
exclude stage 1 input: /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbegin.o
exclude stage 1 input: main.o.ironly
exclude stage 1 input: foo.o.ironly
exclude stage 1 input: bar.o.ironly
exclude stage 1 input: /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgcc_s.so
exclude stage 1 input: /lib64/libc.so.6
exclude stage 1 input: /usr/lib64/libc_nonshared.a(elf-init.oS)
exclude stage 1 input: /lib64/ld-linux-x86-64.so.2
exclude stage 1 input: /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgcc_s.so
exclude stage 1 input: /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtend.o
exclude stage 1 input: /usr/lib/../lib64/crtn.o
attempt to open /usr/lib/../lib64/crt1.o succeeded
/usr/lib/../lib64/crt1.o
attempt to open /usr/lib/../lib64/crti.o succeeded
/usr/lib/../lib64/crti.o
attempt to open /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbegin.o succeeded
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtbegin.o
attempt to open /tmp/ccdj7Ial.ltrans0.ltrans.o succeeded
/tmp/ccdj7Ial.ltrans0.ltrans.o
attempt to open ./libbar.a succeeded
attempt to open /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/libgcc.a succeeded
attempt to open /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgcc_s.so succeeded
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgcc_s.so
attempt to open /usr/lib/../lib64/libc.so succeeded
opened script file /usr/lib/../lib64/libc.so
attempt to open /lib64/libc.so.6 succeeded
/lib64/libc.so.6
attempt to open /usr/lib64/libc_nonshared.a succeeded
(/usr/lib64/libc_nonshared.a)elf-init.oS
attempt to open /lib64/ld-linux-x86-64.so.2 succeeded
/lib64/ld-linux-x86-64.so.2
attempt to open /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/libgcc.a succeeded
attempt to open /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgcc_s.so succeeded
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgcc_s.so
attempt to open /usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtend.o succeeded
/usr/gcc-4.6/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/crtend.o
attempt to open /usr/lib/../lib64/crtn.o succeeded
/usr/lib/../lib64/crtn.o
ld-linux-x86-64.so.2 needed by /lib64/libc.so.6
found ld-linux-x86-64.so.2 at /lib64/ld-linux-x86-64.so.2

The ironly sections are excluded from stage 2 linking. I am
closing.  Please reopen with a testcase if it isn't the case.
Comment 3 Ian Lance Taylor 2010-12-18 05:33:32 UTC
Isn't it premature to close these bugs based on a patch which has not been committed to the mainline sources?
Comment 4 Jan Hubicka 2011-01-05 15:40:06 UTC
Agreed. Until the problem is fixed in mainline, the PR should stay open.