#[thread_local] from windows DLLs gets duplicated by inlining.

[eddyb]

This is most likely responsible for the windows failures from #43931 when the __getit function, which may return a reference to a #[thread_local] static, was #[inline] (cc @alexcrichton):

// a.rs
#![crate_type = "dylib"]
#![feature(thread_local)]

#[thread_local]
static FOO: u32 = 25;

pub fn addr() -> *const u32 {
    &FOO
}

#[inline]
pub fn addr_inline() -> *const u32 {
    &FOO
}

// b.rs
extern crate a;

fn main() {
    assert_eq!(a::addr(), a::addr_inline());
}

Running b, on x64 MSVC (thanks, @bcata6!) results in:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `0x134cb61ace4`,
 right: `0x134cb6139c0`', b.rs:4:4

[alexcrichton]

I think this may be a dllexport/import problem, looks like b.rs is correctly annotated with dllimport but a.rs isn't annotated with dllexport!

[alexcrichton]

Hm no I take that back, I forgot that we don't use dllexport but rather we use link.exe's /DEF argument. I've confirmed that the thread local symbol is indeed listed in that file, and I've also confirmed that it's exported from the DLL. Furthermore I've confirmed again dllimport is applied on the import.

I wonder if this is just not supposed to work? Or maybe this is how TLS works on Windows?

[Zoxc]

MSVC doesn't support this. Tried this on compiler explorer:

#include <stdint.h>

_declspec( dllimport ) thread_local size_t a;

size_t test() {
    return a;
}

I don't know if it's possible or not to do using the DLL loader, but LLVM probably doesn't support it even if it would work.

cc @retep998

[Zoxc]

This also means that the bug applies to thread_local! as there is nothing stopping it from being inlined into other crates.

[mati865]

#44391 (comment) works fine on windows-gnu.

@rustbot modify labels: -O-windows +O-windows-msvc

[ChrisDenton]

To be clear the TLS isn't duplicated, it simply doesn't exist in b.exe.

On Windows, native TLS is scoped to the module (where "module" means either a dll or exe file). So when the dylib is built, the TLS value is in that scope. This would be fine in a normal dll file but Rust's dylibs are special in that they're kind of a weird cross between an actual dll and a static lib. So when compiling an exe with the dylib, the value itself remains declared in the dylib but the (inlined) code for accessing it is moved to the exe, where it ends up referencing some arbitrary memory.

At best it's a STATUS_ACCESS_VIOLATION at worst it accesses something that looks legit but isn't.

[ChrisDenton]

On further investigation it looks like the exe does get an entry embedded in the binary's TLS data array. But it's only one byte no matter the size of the value. And it is always zero initialized. So I guess it is legal to access the first byte of the TLS value. The dylib has the full value in its TLS data array, properly initialized.