Bug 11956

Summary: relocation truncated to fit R_MIPS_TLS_GD linking xulrunner
Product: binutils Reporter: Lluís Batlle <viric>
Component: ldAssignee: unassigned
Status: NEW ---    
Severity: normal CC: bug-binutils, petr.pisar, r0bertz, rixed
Priority: P2    
Version: 2.21   
Target Milestone: ---   
Host: mips64-unknown-linux Target: mips64-unknown-linux
Build: mips64-unknown-linux Last reconfirmed:

Description Lluís Batlle 2010-08-30 07:37:36 UTC

since some time ago (I think all 2.20 versions suffer from this problem too)
xulrunner from firefox 3.6.8 (and some older) don't link properly in mips.

This happens compiling for ABI n32.

r0bertz did some analysis about the problem already two or three months ago, in
the binutils mailing list. And we still have not found any solution:

The last binutils I tried was a snapshot from the 12th of August.

So here you have the symptom. When linking libxul.so, it reports:
../../staticlib/components/libxpconnect.a(xpcjsruntime.o): In function
`XPCJSRuntime::GCCallback(JSContext*, JSGCStatus)':
xpcjsruntime.cpp:(.text+0x1514): relocation truncated to fit: R_MIPS_TLS_GD
against `gTLSIsMainThread'
../../staticlib/components/libxpconnect.a(xpcthreadcontext.o): In function
xpcthreadcontext.cpp:(.text+0x834): relocation truncated to fit: R_MIPS_TLS_GD
against `gTLSIsMainThread'
../../staticlib/components/libnecko.a(nsSocketTransportService2.o): In function
nsSocketTransportService2.cpp:(.text+0x1890): relocation truncated to fit:
R_MIPS_TLS_GD against `gTLSIsMainThread'
../../staticlib/components/libnecko.a(nsSocketTransportService2.o): In function
nsSocketTransportService2.cpp:(.text+0x19e4): relocation truncated to fit:
R_MIPS_TLS_GD against `gTLSIsMainThread'
../../staticlib/components/libuconv.a(nsCharsetConverterManager.o): In function
`nsCharsetConverterManager::GetCharsetAlias(char const*, nsACString_internal&)':
nsCharsetConverterManager.cpp:(.text+0xa78): relocation truncated to fit:
R_MIPS_TLS_GD against `gTLSIsMainThread'
collect2: ld returned 1 exit status

The objects linked have a gcc command-line like this:
c++ -o nsRDFResource.o -c -fvisibility=hidden -DMOZ_ENABLE_GTK2 -DMOZ_PLUGINS
-DIMPL_XREAPI -I../../intl/unicharutil/util -I../../config
-I../../widget/src/windows -I../../widget/src/build  -I. -I.
-I../../dist/include -fPIC   -fno-rtti -fno-exceptions -Wall -Wpointer-arith
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -fno-strict-aliasing
-fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks
-fno-reorder-functions -DMOZILLA_CLIENT -include ../../mozilla-config.h
-Wp,-MD,.deps/nsRDFResource.pp nsRDFResource.cpp

The 'c++' linking command line mentions:
 -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe 
-DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions  -fPIC -shared

Comment 1 Lluís Batlle 2010-08-30 07:38:51 UTC
Additional information: I was using gcc 4.5.1, glibc 2.12.1, kernel headers from
2.6.32, all natively built.
gcc by default produces code for mips3 n32.
Comment 2 Lluís Batlle 2010-08-31 06:58:32 UTC
The problem may be related to a TLS variable exported in a shared object (in the
global-dynamic way).
The TLS variable is gTLSIsMainThread, and the errors from ld come for all the
places where it is used.

The upstream mozilla people decided to disallow TLS completely on mips due to
this binutils problem. More information here:
Comment 3 ZHANG, Le 2010-09-04 20:28:09 UTC

some new findings on the above link
Comment 4 ZHANG, Le 2010-09-05 18:14:34 UTC
sorry the link should be http://sourceware.org/ml/binutils/2010-09/msg00042.html
Comment 5 Jackie Rosen 2014-02-16 19:44:02 UTC
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.