Rollup merge of rust-lang#144234 - roblabla:fix-win7-tls-dtors, r=ChrisDenton

Fix broken TLS destructors on 32-bit win7

Fixes rust-lang#141300

On the 32-bit win7 target, we use OS TLS instead of native TLS, due to issues with how the OS handles alignment. Unfortunately, this caused issues due to the TLS destructors not running, causing memory leaks among other problems.

On Windows, to support OS TLS, the TlsAlloc family of function is used by Rust. This function does not support TLS destructors at all. However, rust has some code to emulate those destructors, by leveraging the TLS support functionality found in the MSVC CRT (specifically, in tlssup.c of the CRT).

To use this functionality, the user must do two things:

1. They must put the address to their callback in a section between `.CRT$XLB` and `.CRT$XLY`.
2. They must add a reference to `_tls_used` (or `__tls_used` on x86) to make sure the TLS support code in tlssup.c isn't garbage collected by the linker.

Prior to this commit, this second bit wasn't being done properly by the Rust TLS support code. Instead of adding a reference to _tls_used, it instead had a reference to its own callback to prevent it from getting GC'd by the linker. While this is _also_ necessary, not having a reference on _tls_used made the entire support non-functional.

This commit reworks the code to:

1. Add an unconditional `#[used]` attribute on the CALLBACK, which should be enough to prevent it from getting GC'd by the linker.
2. Add a reference to `_tls_used`, which should pull the TLS support code into the Rust programs and not let it be GC'd by the linker.

Author: GuillaumeGomez

library/std/src/sys/thread_local/guard/windows.rs

@@ -58,7 +58,7 @@
 //! We don't actually use the `/INCLUDE` linker flag here like the article
 //! mentions because the Rust compiler doesn't propagate linker flags, but
 //! instead we use a shim function which performs a volatile 1-byte load from
-//! the address of the symbol to ensure it sticks around.
+//! the address of the _tls_used symbol to ensure it sticks around.
 //!
 //! [1]: https://www.codeproject.com/Articles/8113/Thread-Local-Storage-The-C-Way
 //! [2]: https://github.com/ChromiumWebApps/chromium/blob/master/base/threading/thread_local_storage_win.cc#L42
@@ -68,9 +68,20 @@ use core::ffi::c_void;
 use crate::ptr;
 use crate::sys::c;
 
+unsafe extern "C" {
+    #[link_name = "_tls_used"]
+    static TLS_USED: u8;
+}
 pub fn enable() {
-    // When destructors are used, we don't want LLVM eliminating CALLBACK for any
-    // reason. Once the symbol makes it to the linker, it will do the rest.
+    // When destructors are used, we need to add a reference to the _tls_used
+    // symbol provided by the CRT, otherwise the TLS support code will get
+    // GC'd by the linker and our callback won't be called.
+    unsafe { ptr::from_ref(&TLS_USED).read_volatile() };
+    // We also need to reference CALLBACK to make sure it does not get GC'd
+    // by the compiler/LLVM. The callback will end up inside the TLS
+    // callback array pointed to by _TLS_USED through linker shenanigans,
+    // but as far as the compiler is concerned, it looks like the data is
+    // unused, so we need this hack to prevent it from disappearing.
     unsafe { ptr::from_ref(&CALLBACK).read_volatile() };
 }