Roadmap: native ARM64 toolchain (w64devkit-arm64, aarch64-w64-mingw32)

[skeeto]

Due to Windows' built-in, transparent x86/x64 emulation — which is honestly quite impressive! — w64dk already works out-of-the-box on ARM64, if with a performance penalty. (Though busybox-w32 in emulation thinks the user is named root? This needs investigation.) GCC 15 has partial, tentative support for aarch64-w64-mingw32. So perhaps it's time to explore an ARM64 toolchain. Lacking C++ exceptions, initial attempts will likely only support C. This issue is an open invitation to try it out and report results/findings.

Will the lack of C++ exceptions interfere with the ARM64 cross-builds of GCC, GDB, and 7z SFX? These are written in C++. Can GDB even debug Windows ARM64 targets (current guess: no)? I won't consider it ready, even with just a C toolchain, without a working debugger. If these components cannot be compiled for ARM64, perhaps they remain x64 such that it's actually a C cross-toolchain hosted on x64 targeting ARM64. This would all be transparent to users.

Regardless, a complete toolchain will require eventually porting libmemory and libchkstk.

[Peter0x44]

@ssbssa was working on an aarch64-w64-mingw32 gdb and I think had some progress.
There's quite a lot of work remaining upstream. @Blackhex has talked to me about it before.

The Snapdragon X elite hardware I tried was fairly unimpressive. Not performing any better than Intel or AMD equivalents and of course you deal with incompatibilities too. Hopefully the x2 elite is significantly better. This was about a year ago though, and I expect things to have improved significantly since.

One of the worst parts was Qualcomm putting driver downloads behind accounts. That was really obnoxious...

The current best options for aarch64 windows is llvm-mingw. It has supported it for years.
Not sure if it's worth consideration to provide a clang variant or not. It's not a problem for me to keep both on my PATH, I use them both regularly.

[rmyorston]

Though busybox-w32 in emulation thinks the user is named root?

I don't see that when I run the x86_64 FRP-5857 release on my Windows on ARM machine (with a local account). Both the user, as reported by whoami, and files belonging to the user have the correct name.

Does your alleged "root" user have elevated privileges?

Since I have a native aarch64 build of busybox-32 I'm not in the habit of running the x86_64 binary. It seems to work better now than it did when I last tried it a couple of years ago. The testsuite gives the same results as the aarch64 binary, where previously there were additional failures. It's slower, of course.

[skeeto]

Thanks for the info, @Peter0x44!

One of the worst parts was Qualcomm putting driver downloads behind accounts.

Ugh. I had the opposite experience about a year ago. An acquaintance was getting rid of a dusty, old 2008-era laptop, and I snagged it for w64dk testing. Dell still hosts all the old drivers for this model on their site, no accounts required. Had it up and running with a fresh, clean install in no time. I appreciate that kind of long-term support.

Does your alleged "root" user have elevated privileges?

Turns out this is a system configuration issue on my end, and I was indeed running everything with elevated privileges. In my investigation I GDB-stepped into whoami.c to understand what was going on, and observed the elevated token. After adjusting the User Account Control settings back to the "default" level, busybox-w32 looks fine. It was the first application I ran that suggested anything was amiss! Sorry for the bother!

This is a fresh install using a Windows 11 25H2 ISO which I just downloaded from Microsoft yesterday. I definitely didn't configure it to run like this, and I didn't even know it was possible. I've installed Windows 11 a bunch of times on x64 with previous installers, and this has never happened to me before. Might be some new installer bug? It's also the first time without a hassle creating a local account — an ARM64 thing, or some recent change?

[Peter0x44]

https://www.qualcomm.com/developer/blog/2025/08/upgrade-latest-graphics-driver-snapdragon-x-elite-devices-310112

Disappointed to learn they're still doing it...

If you’ve already registered, you can [access the graphics driver now]
(https://softwarecenter.qualcomm.com/#/catalog/item/Windows_Graphics_Driver); otherwise, register here, then access the graphics driver.

[Peter0x44]

Actually despite the contradictory wording on that page the link still works without an account. Spoke too soon.