std: Add an option to disable ELF based TLS

[alexcrichton]

This commit adds a ./configure option called --disable-elf-tls which disables
ELF based TLS (that which is communicated to LLVM) on platforms which already
support it. OSX 10.6 does not support this form of TLS, and some users of Rust
need to target 10.6 and are unable to do so due to the usage of TLS. The
standard library will continue to use ELF based TLS on OSX by default (as the
officially supported platform is 10.7+), but this adds an option to compile the
standard library in a way that is compatible with 10.6.

Closes #25342

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

cc @rillian, this means that the custom build of Rust that Firefox uses will need to pass --disable-elf-tls to the ./configure script, but other than that everything should work out just fine!

[rillian]

Thanks, @alexcrichton!

I'm confused by 'ELF based TLS'. Is this the appropriate terminology for the same feature in Mach-O?

[alexcrichton]

Ah yeah maybe it isn't the best name after all, I was going off the LLVM documentation which indicates:

The models correspond to the ELF TLS models; see ELF Handling For Thread-Local Storage for more information on under which circumstances the different models may be used. The target may choose a different TLS model if the specified model is not supported, or if a better choice of model can be made.

So maybe a more appropriate name would be --disable-elf-like-tls :)

[rillian]

So maybe a more appropriate name would be --disable-elf-like-tls :)

Lol. If the alternative is a pthread_get/setspecific-based implementation, would plain --disable-tls be too confusing? Otherwise --disable-linker-tls? // bikeshed

[rillian]

This doesn't seem to be sufficient. I built yesterday's rustc master with you pr merged, and the linkage gtest we have in the gecko tree fails with

0:06.36 ld: targeted OS version does not support use of thread local variables in __ZN10sys_common11thread_info14current_thread20h5eac201a4bb7b339c8qE for architecture x86_64
0:06.36 clang: error: linker command failed with exit code 1 (use -v to see invocation)
0:06.36 make[2]: *** [XUL] Error 1

Sounds like std::sys::current_thread(). Is the thread_local! macro change not being propagated properly? Did I mess up my build somehow?

[alexcrichton]

Hm that's surprising, so you basically did this?

• Checked out the current master of rust-lang/rust
• Applied this PR
• Configured with --disable-elf-tls
• make
• ./x86_64-apple-darwin/stage2/bin/rustc foo.rs <- and this failed?

[rillian]

No, that has always worked, I assume because rustc does the linking in that case. The gecko build calls rustc --create-type staticlib foo.rs which has also always worked. The error comes when the gecko build later invokes Apple's ld with MACOSX_DEPLOYMENT_TARGET=10.6 set in the environment to link the resulting libfoo.a into the C++ library which calls it. It recongnizes the TLS segments (or whatever it is in mach-o) and balks.

So:

• Checked out the current rust-lang/rust master
• Applied this PR
• ./configure --prefix=${HOME}/.local/rust-notls --disable-elf-tls
• make -j8 && make install
• export PATH=$PATH:${HOME}/.local/rust-notls/bin
• export DYLD_LIBRARY_PATH=${HOME}/.local/rust-notls
• Checkout mozilla/gecko-dev master
• echo --enable-rust >> mozconfig
• Hack configure do disable the rust+10.6 interlock
• ./mach build
• ./mach gtest rust.*

[rillian]

A much simpler test is https://github.com/rillian/rust-ffi test

$ git clone https://github.com/rillian/rust-ffi
[...]
$ cd rust-ffi/
$ make MACOSX_DEPLOYMENT_TARGET=10.7
rustc --crate-type staticlib test.rs 2> libtest.a.out
c++ -g -Wall -std=c++1y -c TestRust.cpp
c++ -g -Wall -std=c++1y -o test TestRust.o libtest.a -lSystem -lpthread -lc -lm
$ make clean
[...]
$ make MACOSX_DEPLOYMENT_TARGET=10.6
rustc --crate-type staticlib test.rs 2> libtest.a.out
c++ -g -Wall -std=c++1y -c TestRust.cpp
c++ -g -Wall -std=c++1y -o test TestRust.o libtest.a -lSystem -lpthread -lc -lm
ld: targeted OS version does not support use of thread local variables in __ZN6thread7current20h6880357b0f286e7cVxbE for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [test] Error 1

[rillian]

Well, that was with the rust 1.0.0 compiler. I works with the --disable-elf-tls build, so it's probably me.

[alexcrichton]

export PATH=$PATH:${HOME}/.local/rust-notls/bin

Perhaps you had a rustc which was listed first in your PATH? Are you sure the --disable-elf-tls build was used by Gecko?

[rillian]

I must have been. I did a clean build of both and it works now. Sorry for the confusion.

Works for me, please merge!

[alexcrichton]

No worries, thanks for the confirmation @rillian!

[brson]

@bors r+

[bors]

📌 Commit 1b5f9cb has been approved by brson

[bors]

⌛ Testing commit 1b5f9cb with merge a49ae5b...

[alexcrichton]

I think I borked my branch here, but all tests passed so merging manually.

[rillian]

@alexcrichton What do you think about backporting this to 1.1?

[alexcrichton]

@rillian I figured you guys were building from source anyway, so would building from the 1.1 source be better than building from the master source? I don't think we'll be shipping a binary build of this unfortunately regardless.

[rillian]

We could build from stable release source sooner, that's all.

[alexcrichton]

Eh, may as well nominate and see what happens!

[alexcrichton]

Discussed with @brson and we decided to accept for backporting.

[rillian]

Lovely, thanks!