Skip to content

Commit e25c4fa

Browse files
borsbors
committed
Auto merge of #108089 - Zoxc:windows-tls, r=bjorn3
Support TLS access into dylibs on Windows This allows access to `#[thread_local]` in upstream dylibs on Windows by introducing a MIR shim to return the address of the thread local. Accesses that go into an upstream dylib will call the MIR shim to get the address of it. `convert_tls_rvalues` is introduced in `rustc_codegen_ssa` which rewrites MIR TLS accesses to dummy calls which are replaced with calls to the MIR shims when the dummy calls are lowered to backend calls. A new `dll_tls_export` target option enables this behavior with a `false` value which is set for Windows platforms. This fixes rust-lang/rust#84933.
2 parents 7d947a0 + dc07d90 commit e25c4fa

File tree

2 files changed

+4
-48
lines changed

2 files changed

+4
-48
lines changed

‎std/src/sys/common/thread_local/fast_local.rs

Lines changed: 2 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@
1010
macro_rules! __thread_local_inner {
1111
// used to generate the `LocalKey` value for const-initialized thread locals
1212
(@key $t:ty, const $init:expr) => {{
13-
#[cfg_attr(not(windows), inline)] // see comments below
13+
#[cfg_attr(not(bootstrap), inline)]
1414
#[deny(unsafe_op_in_unsafe_fn)]
1515
unsafe fn __getit(
1616
_init: $crate::option::Option<&mut $crate::option::Option<$t>>,
@@ -77,29 +77,7 @@ macro_rules! __thread_local_inner {
7777
#[inline]
7878
fn __init() -> $t { $init }
7979

80-
// When reading this function you might ask "why is this inlined
81-
// everywhere other than Windows?", and that's a very reasonable
82-
// question to ask. The short story is that it segfaults rustc if
83-
// this function is inlined. The longer story is that Windows looks
84-
// to not support `extern` references to thread locals across DLL
85-
// boundaries. This appears to at least not be supported in the ABI
86-
// that LLVM implements.
87-
//
88-
// Because of this we never inline on Windows, but we do inline on
89-
// other platforms (where external references to thread locals
90-
// across DLLs are supported). A better fix for this would be to
91-
// inline this function on Windows, but only for "statically linked"
92-
// components. For example if two separately compiled rlibs end up
93-
// getting linked into a DLL then it's fine to inline this function
94-
// across that boundary. It's only not fine to inline this function
95-
// across a DLL boundary. Unfortunately rustc doesn't currently
96-
// have this sort of logic available in an attribute, and it's not
97-
// clear that rustc is even equipped to answer this (it's more of a
98-
// Cargo question kinda). This means that, unfortunately, Windows
99-
// gets the pessimistic path for now where it's never inlined.
100-
//
101-
// The issue of "should enable on Windows sometimes" is #84933
102-
#[cfg_attr(not(windows), inline)]
80+
#[cfg_attr(not(bootstrap), inline)]
10381
unsafe fn __getit(
10482
init: $crate::option::Option<&mut $crate::option::Option<$t>>,
10583
) -> $crate::option::Option<&'static $t> {

‎std/src/sys/common/thread_local/os_local.rs

Lines changed: 2 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@
1010
macro_rules! __thread_local_inner {
1111
// used to generate the `LocalKey` value for const-initialized thread locals
1212
(@key $t:ty, const $init:expr) => {{
13-
#[cfg_attr(not(windows), inline)] // see comments below
13+
#[cfg_attr(not(bootstrap), inline)]
1414
#[deny(unsafe_op_in_unsafe_fn)]
1515
unsafe fn __getit(
1616
_init: $crate::option::Option<&mut $crate::option::Option<$t>>,
@@ -49,29 +49,7 @@ macro_rules! __thread_local_inner {
4949
#[inline]
5050
fn __init() -> $t { $init }
5151

52-
// When reading this function you might ask "why is this inlined
53-
// everywhere other than Windows?", and that's a very reasonable
54-
// question to ask. The short story is that it segfaults rustc if
55-
// this function is inlined. The longer story is that Windows looks
56-
// to not support `extern` references to thread locals across DLL
57-
// boundaries. This appears to at least not be supported in the ABI
58-
// that LLVM implements.
59-
//
60-
// Because of this we never inline on Windows, but we do inline on
61-
// other platforms (where external references to thread locals
62-
// across DLLs are supported). A better fix for this would be to
63-
// inline this function on Windows, but only for "statically linked"
64-
// components. For example if two separately compiled rlibs end up
65-
// getting linked into a DLL then it's fine to inline this function
66-
// across that boundary. It's only not fine to inline this function
67-
// across a DLL boundary. Unfortunately rustc doesn't currently
68-
// have this sort of logic available in an attribute, and it's not
69-
// clear that rustc is even equipped to answer this (it's more of a
70-
// Cargo question kinda). This means that, unfortunately, Windows
71-
// gets the pessimistic path for now where it's never inlined.
72-
//
73-
// The issue of "should enable on Windows sometimes" is #84933
74-
#[cfg_attr(not(windows), inline)]
52+
#[cfg_attr(not(bootstrap), inline)]
7553
unsafe fn __getit(
7654
init: $crate::option::Option<&mut $crate::option::Option<$t>>,
7755
) -> $crate::option::Option<&'static $t> {

0 commit comments

Comments
 (0)