`#[thread_local]` alignment broken on Windows, GNU ABI

[purplesyringa]

I tried this code:

#![feature(thread_local)]

#[repr(align(256))]
struct HighAlignment(u8);

#[thread_local]
static EXAMPLE1: HighAlignment = const { HighAlignment(0) };
#[thread_local]
static EXAMPLE2: HighAlignment = const { HighAlignment(0) };
#[thread_local]
static EXAMPLE3: HighAlignment = const { HighAlignment(0) };

fn main() {
    println!(
        "{:?}, {:?}, {:?}",
        &EXAMPLE1 as *const HighAlignment,
        &EXAMPLE2 as *const HighAlignment,
        &EXAMPLE3 as *const HighAlignment
    );
}

I expected to see this happen: three 0x100-aligned pointers.

Instead, this happened: metal pipe falling

• x86_64, GNU ABI, real Windows: 0x1f39e953850, 0x1f39e953950, 0x1f39e953a50 (unaligned)
• x86_64, MSVC ABI, real Windows: 0x1c287893900, 0x1c287893a00, 0x1c287893b00 (aligned)
• i686, GNU ABI, real Windows: 0xf9a5f8, 0xf9a6f8, 0xf9a7f8 (unaligned)
• i686, MSVC ABI, real Windows: 0x6d2f00, 0x6d3000, 0x6d3100 (aligned)
• x86_64, GNU ABI, Wine: 0x232c80, 0x232d80, 0x232e80 (unaligned)
• x86_64, MSVC ABI, Wine: 0x1320e0, 0x1321e0, 0x1322e0 (unaligned)
• i686, GNU ABI, Wine: 0x341f28, 0x342028, 0x342128 (unaligned)
• i686, MSVC ABI, Wine: 0x34f010, 0x34f110, 0x34f210 (unaligned)

So either this affects all of Windows and I just got lucky twice, or this is two bugs in a trenchcoat, one affecting GNU ABI and another one in Wine. Not sure which.

Notably, checking mixed-alignment thread locals, like u8, u8, u128, u128, u128, shows that the variables are correctly aligned with respect to each other within TLS, but the TLS base itself seems to be unaligned.

Tentatively marking as I-unsound because of unaligned references bad, feel free to retag.

Meta

rustc --version --verbose:

rustc 1.86.0-nightly (419b3e2d3 2025-01-15)
binary: rustc
commit-hash: 419b3e2d3e350822550eee0e82eeded4d324d584
commit-date: 2025-01-15
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.6

wine --version: wine-9.22 (Staging)

Tracking issue for visibility: #29594

[Noratrieb]

Does this also reproduce with std::thread_local?

Also what exactly do you mean with Wine here? Building it normally on Windows and running it with Wine? Building it in Wine too?

[purplesyringa]

Also what exactly do you mean with Wine here?

The real Windows vs Wine separation refers to the environment the code is run in.

I haven't considered building the code in different environments. All GNU targets were cross-compiled on Linux, all MSVC targets were compiled with cargo-xwin. I don't have access to a Windows machine right now, someone should probably try building directly on Windows, too, although I doubt there'd be a difference in the produced executables.

Does this also reproduce with std::thread_local?

Eugh, kind of.

#[repr(align(256))]
struct HighAlignment(u8);

thread_local! {
    static EXAMPLE1: HighAlignment = const { HighAlignment(0) };
}
thread_local! {
    static EXAMPLE2: HighAlignment = const { HighAlignment(0) };
}
thread_local! {
    static EXAMPLE3: HighAlignment = const { HighAlignment(0) };
}

fn main() {
    EXAMPLE1.with(|a| {
        EXAMPLE2.with(|b| {
            EXAMPLE3.with(|c| {
                println!(
                    "{:?}, {:?}, {:?}",
                    a as *const HighAlignment, b as *const HighAlignment, c as *const HighAlignment
                );
            })
        })
    });
}

Gives unaligned addresses on Wine on i686-pc-windows-msvc and only that target. I'm going offline now, but it's worth trying to run this on real Windows. If it turns out it applies there too, congratulations, we have a stable unsoundness.

[Fulgen301]

Running that sample on real Windows yields

0xdcdf00, 0xdce000, 0xdce100

, so it's fine.

[purplesyringa]

Turns out x86_64-pc-windows-msvc on Wine also gives unaligned access on the snippet above if you run the code in another thread (i.e.: wrap main in spawn+join). I haven't managed to reproduce this thread_local! bug on GNU ABI (still under Wine) and I don't see a clear reason why -- I hold that there's a possibility that aligned allocations are just a coincidence. I'll see if I can get my hands on Windows to play around with this more.