On Mon Jan 27 13:11:58 2025 +0000, Jinoh Kang wrote:
Feel free to correct me though; in any case I'm not an active contributor to MSYS2/MinGW and it's very possible that I got details completely wrong. I just wanted to clarify what was arguably initially vague from my side. In any case, thanks for your patience. (Please excuse me if my replies are late; I'm currently on vacation and my timezone GMT+9 is quite distant from some other Wine contributors.)
Thanks for the clarifications. Yes, your understanding sounds mostly correct.
In practice, the vast majority of the "mingw-ism" are quite platform independent, so most of them (like the Itanium C++ ABI etc, prebuilt defines like `__MINGW32__` etc) are just brought over in the exact same form as on x86. So the amount of "LLVM got to decide first what the MinGW constructs mean on Windows ARM" was, in practice, 95% just copying the existing practices on x86.
(Also, as a practical detail, surprisingly little of the actual details of what a mingw toolchain needs to do are encoded in the actual mingw-w64 source; most of it is conventions within GCC/binutils and within LLVM/Clang.)
There are, practically, essentially only 2 architecture specific cases where we in LLVM did take the lead and settle on ABI details that we'd want GCC to follow now when they're catching up:
- The kind of `long double`. On x86, mingw uses 80 bit `long double`, while MSVC uses 64 bit bit ones. As x86 does have hardware for 80 bit floats, this somewhat seems sensible, but it causes an endless source of extra work within the mingw ecosystem (we can't ever use anything from UCRT/msvcrt regarding long doubles). Aarch64 doesn't have any >64 bit floats in hardware. There, MSVC uses 64 bit long doubles, Darwin does the same. Linux uses 128 bit softfloats for `long double` though. To avoid unnecessary divergence, unnecessary extra work, and avoiding relying on slow softfloats, we matched the MSVC ABI and went with 64 bit `long double`s. The in-progress GCC port for this target uses 128 bit long doubles, currently - diverging from the already established ABI. This ABI detail is visible quite a lot within the mingw-w64 code though; a lot of the math functions for aarch64 do assume that `long double` is equal to regular `double`, so currently the GCC port has to patch a lot of that code. They have signaled that they will switch to 64 bit long doubles to match LLVM though.
- The name of the stack probe function. On MSVC, the stack probe function is called `__chkstk`, on all architectures. Within mingw environments on x86, it's called `_alloca` on i386 and `___chkstk_ms` on x86_64, while it retains the same (custom) calling convention as MSVC. For arm and aarch64, we didn't see any reason to deviate from what MSVC does, so we use the same name, `__chkstk`. For the GCC port, they don't provide any stack probe function at all yet, and just expand the stack probing inline in function prologues. (This would break Clang-built code if linked against the GCC port's libgcc though.) This aspect is not visible at all in the mingw-w64 repo itself; it's in practice a contract between the code generation code (in GCC/Clang) and the runtime library (in libgcc or compiler-rt).