Add support for mingw targets

[seritools]

As requested in #23.

Any progress?

[seritools]

There have been no contributions on this, no.

[cher-nov]

I'm open to contributions there, but won't be implementing it myself.

Could you then please outline some kind of roadmap for this? I'd like to try my hand at making this happen, but would like to know where to start. The Rust codebase is a pretty non-obvious thing after all, y'know. :)

[seritools]

@cher-nov I am unfamiliar with the mingw targets and hacks necessary, but roughly it'll be

1. add targets for rust9x + mingw (see the relevant commit on the rust9x branch)
2. fix things until they build
3. fix things until they link
4. fix things until they run
5. fix things until they run correctly

Please note that I've also started work on a rust9x update/rebase for ~1.83, which changes a few things.

[cher-nov]

Please note that I've also started work on a rust9x update/rebase for ~1.83, which changes a few things.

This is great, endless thanks. One question: will the rustc itself continue to work on Windows 7 as host system, or rust9x project is only about target platforms? Because starting from 1.78.x the mainline became incompatible with it.
https://blog.rust-lang.org/2024/02/26/Windows-7.html

[seritools]

Rustc itself might work with rust9x, however that is not supported by me. In particular external deps of rustc, cargo, ... might use incompatible APIs and would need patching.

For the update I'm also aiming to use more conditional compilation so that my changes do not affect the normal pc-windows-msvc targets (at least as much, we'll see).

[ssokolow]

I suppose the question for Win7 host support boils down to checking how far that Tier 3 x86_64-win7-windows-msvc target is from getting its Host checkmark.

(Failing that, my own options for experimenting with targeting my retro-hobby PCs using Rust9x are either trying to run the prebuilt x86_64 offering in Wine or figuring out what I need to cross-compile from Linux. Unless I try swtching one of the "RasPi 4, but x86"-class mini-PCs I received as a hand-me-down back from Debian to the Windows 10 they came with, the newest Windows I've got is Win7.)

[Fenex]

This is great, endless thanks. One question: will the rustc itself continue to work on Windows 7 as host system, or rust9x project is only about target platforms? Because starting from 1.78.x the mainline became incompatible with it.

I have built Rust 1.91 (and some earlier) as host tools for windows 7 use rust-lang/rust source code without any changes, thus I believe we can compile modern version of rustc with host x86_64-win7-windows-msvc and targets *-rust9x-windows-msvc with no hard challenges.

Related PR that adds note to docs about success compiling host tools for windows 7: rust-lang#148362.

[Aerocatia]

FWIW, you can make win9x compatible executable using this mingw release https://github.com/redpanda-cpp/mingw-lite mingw32_686-msvcrt_win98-15.2.0-r7 and upstream i686-pc-windows-gnu provided it's nostd

So I assume on top of this you need to handle not using too-new win32 APIs in std as usual, and do something about using x87 floating point math instead of sse.

[K4sum1]

So I later found that setting Firefox to compile with minwg32 does basically nothing. It's just a compatibility shim that they just recently removed. I literally did not have any mingw32 installed to use when I was setting it. It just uses the same Clang + VS toolchain but with mingw32 in the target name.

[Jookia]

Greetings Rust9x friends. I managed to make some progress in this, though I haven't gotten working binaries yet. I'm not sure how much further I will take this but I'll document my progress here.

First up, I'm using Arch with the stock mingw-w64. This was a bad idea, I should have used mingw-lite in hindsight. I'll explain why later.

First up, building Rust works okay-ish. I added in some new target triples i586-rust9x-windows-gnu and i686-rust9x-windows-gnu. I went through the source tree and looked at where to add it and I also updated places where 'pc-windows-gnu' is used to just watch 'windows-gnu'. I even created a bootstrap file.

I couldn't get stage0 to recognize the target so I had to dump JSON files for the targets. I also found that I'd have to update the 'cc' crate for it to find the correct compiler, so a workaround for that is to set the CC environment flag.

Here is my very work in progress diff for anyone wanting to follow along: https://gist.github.com/Jookia/0f79886780630cc34cc5e84c3ce382f6

To build it you do something like this:

CC=i686-w64-mingw32-gcc ./x --config bootstrap.rust9x-gnu.toml build library

I think went ahead and tried to build a project using sdl3, with it set to build from source. your Rust project add this .cargo/config.toml file.

[build]

[env]
CC = 'i686-w64-mingw32-gcc'
CXX = 'i686-w64-mingw32-g++'
LD = 'i686-w64-mingw32-ld'
CFLAGS = '-march=i586 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501'

[target.'cfg(target_family = "rust9x")']
rustflags = [
  '-Clink-arg=-lgdi32',
  '-Clink-arg=-lversion',
  '-Clink-arg=-lshell32',
  '-Clink-arg=-lwinmm',
  '-Clink-arg=-ladvapi32',
]

I have no idea how much the CFLAGS help. But this did build me an exe that lacked calls to ntdll or CPU SSE extensions, which is good! Unfortunately it links to the UCRT, not MSVCRT. So you will get errors looking for friends like api-ms-win-crt-stdio-l1-1-0.dll.

As a workaround you can install the Visual C++ 2015 Redistributable pack which provides them, but this isn't really a long term solution.

Anyway, here's a screenshot of the SDL3 example:

Here's the rust9x_sample.exe running:

I didn't have the data file copied over so it errors.

With a bit of cleanup I think this could be a viable way to cross-compile to Windows XP, though I really think the other C compiler needs to be used.

---

That said, there is a larger problem: Rust requires the Vista-era InitOnceBeginInitialize function for running destructors or something. I dummied it out in library/std/src/sys/thread_local/key/windows.rs but fixing this probably requires going back to some old logic. I don't quite understand why this hasn't been noticed, is this something MSVC is shimming?

Edit: This is on a Pentium 3 running Windows XP for context.

[seritools]

That said, there is a larger problem: Rust requires the Vista-era InitOnceBeginInitialize function for running destructors or something. I dummied it out in library/std/src/sys/thread_local/key/windows.rs but fixing this probably requires going back to some old logic. I don't quite understand why this hasn't been noticed, is this something MSVC is shimming?

MSVC targets use the native target thread local support, which lets the runtime handle some of the work, so the entire key/windows.rs impl including InitOnce is not necessary for MSVC:

rust/library/std/src/sys/thread_local/mod.rs

Lines 165 to 170 in 25a5ea7

	all(not(target_thread_local), target_os = "windows") => {
	#[cfg(test)]
	mod tests;
	mod windows;
	pub(super) use windows::{Key, LazyKey, get, run_dtors, set};
	}

rust/compiler/rustc_target/src/spec/base/windows_msvc.rs

Line 34 in 25a5ea7

has_thread_local: true,

[Jookia]

I talked to seri last night on Discord, and I was given some wisdom. Notably that the -gnu targets are kind of broken (see https://github.com/rust-lang/rust/issues?q=state%3Aopen%20label%3AO-windows-gnu for a full view) and -gnullvm is where the future is. I have a bunch of notes, so I'll dump them here.

First: 32-bit Windows seems to demand x87 for passing floats around. The x87 floats are kind of broken due to issues like double rounding and NaN canonicalisation happening when you load/store floats. Compilers seem to assume load/stores aren't harmful but this isn't the case. Using SSE2 kind of defeats the point of this project anyway, but it's worth noting that even then you still have problems with FFI at the very least. The NaN boxing issue is probably the biggest one I can think of since people like to store data in NaNs for language like Lua or JavaScript. There's not much we can do about this, but it's also not a blocker as much as 'floats are kinda wonky, be happy you have them in the first place'

As a fun fact, the m68k FPU had this issue too but they fixed it in the 68040 when they added instructions that specify the precision you want. I assume they don't mangle NaN values. So m68k Rust is probably having a much better time with floats.

Second: Runtimes. Rust currently aims to use the MSVCRT library and MSYS2 and friends are moving towards it. This block platforms older than Windows XP as that's the earliest you can get a UCRT build for. Rust9x could target MSVCRT and we can always build MinGW to use MSVCRT too. Somewhat adjacent is MinGW using POSIX threads instead of Win32 threads.

Third: -gnullvm isn't going to work on older platforms. It uses its own set of runtimes instead of libgcc and these require Vista onwards for threading and apparently 7 onwards for some other functionality (I couldn't confirm the Windows 7 part but I'd believe it). It also supports std::thread natively which is nice. Clang aims to be compatible with MSVC ABIs which is cool too. I'd probably want to use this for real world Rust projects.

Fourth: Thread local storage. This is a tricky one because GCC 16 and LLVM both support native Windows thread-local storage, but this requires Vista APIs. Our only option here is to emulate it, and GCC does this with emulated TLS. In fact proper threading requires Vista onwards because it adds conditional variables, read/writer locks, and one-time initialization.

So we're kind of in a tricky situation where we have to use MSVCRT, POSIX threads, and emulated TLS. The latter two seem to be a recipe for a few -windows-gnu bugs, and I don't know if they're going to be fixed that easily.

Circling back to yesterday's blocker, GCC should have thread local support. I read through many github issues related to thread_local and MinGW and couldn't find a solid reason to not enable it, or bugs that only happen on MinGW with thread_local. I enabled thread_local support and tested it, it seems fine.

I also went ahead and rewrote the thread_local/key/windows.rs code, replacing the initialize once with an atomic flag and a mutex. Here's the patch, it looks reasonable to me:

diff --git a/library/std/src/sys/thread_local/key/windows.rs b/library/std/src/sys/thread_local/key/windows.rs
index 2ff0fd1196e..0f324be7661 100644
--- a/library/std/src/sys/thread_local/key/windows.rs
+++ b/library/std/src/sys/thread_local/key/windows.rs
@@ -24,10 +24,10 @@
 // FIXME: investigate using a fixed-size array instead, as the maximum number
 //        of keys is [limited to 1088](https://learn.microsoft.com/en-us/windows/win32/ProcThread/thread-local-storage).

-use crate::cell::UnsafeCell;
 use crate::ptr;
 use crate::sync::atomic::Ordering::{AcqRel, Acquire, Relaxed, Release};
-use crate::sync::atomic::{Atomic, AtomicPtr, AtomicU32};
+use crate::sync::atomic::{Atomic, AtomicPtr, AtomicBool, AtomicU32};
+use crate::sync::Mutex;
 use crate::sys::c;
 use crate::sys::thread_local::guard;

@@ -43,8 +43,8 @@ pub struct LazyKey {
     next: Atomic<*mut LazyKey>,
     /// Currently, destructors cannot be unregistered, so we cannot use racy
     /// initialization for keys. Instead, we need synchronize initialization.
-    /// Use the Windows-provided `Once` since it does not require TLS.
-    once: UnsafeCell<c::INIT_ONCE>,
+    pending: AtomicBool,
+    initing: Mutex<()>,
 }

 impl LazyKey {
@@ -54,7 +54,8 @@ pub const fn new(dtor: Option<Dtor>) -> LazyKey {
             key: AtomicU32::new(0),
             dtor,
             next: AtomicPtr::new(ptr::null_mut()),
-            once: UnsafeCell::new(c::INIT_ONCE_STATIC_INIT),
+            pending: AtomicBool::new(true),
+            initing: Mutex::new(()),
         }
     }

@@ -69,16 +70,26 @@ pub fn force(&'static self) -> Key {
     #[cold]
     unsafe fn init(&'static self) -> Key {
         if self.dtor.is_some() {
-            let mut pending = c::FALSE;
-            let r = unsafe {
-                c::InitOnceBeginInitialize(self.once.get(), 0, &mut pending, ptr::null_mut())
-            };
-            assert_eq!(r, c::TRUE);
-
-            if pending == c::FALSE {
+            let pending = self.pending.load(Acquire);
+            if pending == false {
                 // Some other thread initialized the key, load it.
+                // We can use Relaxed here because pending will ensure
+                // key has been initialized.
                 self.key.load(Relaxed) - 1
             } else {
+                let Ok(_lock_guard) = self.initing.lock() else {
+                    rtabort!("failed to lock TLS init lock");
+                };
+
+                // Multiple threads may have seen pending as true and
+                // tried to initialize it. We have the lock now,
+                // but we may not have the first to get it.
+                // Check if it was already initialized.
+                let pending2 = self.pending.load(Acquire);
+                if pending2 == false {
+                    return self.key.load(Relaxed) - 1
+                }
+
                 let key = unsafe { c::TlsAlloc() };
                 if key == c::TLS_OUT_OF_INDEXES {
                     // Since we abort the process, there is no need to wake up
@@ -91,15 +102,15 @@ unsafe fn init(&'static self) -> Key {
                     register_dtor(self);
                 }

-                // Release-storing the key needs to be the last thing we do.
-                // This is because in `fn key()`, other threads will do an acquire load of the key,
-                // and if that sees this write then it will entirely bypass the `InitOnce`. We thus
-                // need to establish synchronization through `key`. In particular that acquire load
-                // must happen-after the register_dtor above, to ensure the dtor actually runs!
+                // Store key with a Release to ensure loaders have
+                // access to our destructor.
                 self.key.store(key + 1, Release);

-                let r = unsafe { c::InitOnceComplete(self.once.get(), 0, ptr::null_mut()) };
-                debug_assert_eq!(r, c::TRUE);
+                // Store pending with a release to ensure any pending
+                // loads see the key store value. This ensures we won't
+                // ever hit a situation of finding pending false and
+                // the key uninitialized.
+                self.pending.store(false, Release);

                 key
             }