No rustc or cargo for aarch64-pc-windows-msvc

[tleasor]

Currently there are no native rustc or cargo binaries for Windows on ARM64. The 32-bit x86 binaries (i686-pc-windows-msvc) work correctly, but suffer a noticeable performance and battery life penalty.

I've tried to build rustc myself, but have had quite a few issues trying to cross-compile it since there are no pre-built bootstrap binaries for aarch64-pc-windows-msvc. Cargo builds without issue, but doesn't make much sense without a native rustc.

What would it take to get this working and available via rustup? I'm happy to keep working on this myself but am slightly lost as to how to proceed.

[tleasor]

I've managed to cross-compile rustc, cargo and most of the default components now after fixing a build issue in a dependency (psm), but unfortunately the built compiler doesn't work. Trying to compile the default "hello world" project fails silently when using rustc directly, and cargo fails with a "STATUS_ACCESS_VIOLATION" error, which seems to be a memory-related issue.

[Stammark]

I have also been experimenting with this on our side! I had successfully built a rustc using older source code (April 30th nightly comes to mind), but the STATUS_ACCESS_VIOLATION errors started happening after the stacker/psm dependency got added, so I investigated that for a bit and just raised this:

https://developercommunity.visualstudio.com/content/problem/1088946/armasm64-not-erroring-when-given-no-area-name-give.html

I think that just adding a dummy area name might solve that. I haven't tested this properly for rustc, yet, though. The latest I got to last was getting problems with my stage0 being too old to compile current head-of-trunk-nightly.

I also had issues with compiling RLS due to the use of the old winapi 0.2.8, through mio 0.6.X and tokio, but this should fix itself when tokio fully updates to mio 0.7 instead of mio 0.6.X (see tokio-rs/tokio#1190 )

[tleasor]

@Stammark Thanks for the tip! Adding a dummy area name in psm has resulted in a working rustc binary.

Compilation times are greatly improved in my limited testing (I've seen 40-50% reductions so far, I'll compile a few popular projects to get some accurate numbers which I'll post here).

One issue that I've noticed is that it fails to find link.exe, which the x86 rustc finds without issue (I'm working around this using the VS Developer Command Prompt at the moment). I've skimmed the relevant code and it looks like I just need to fix the cc dependency to use x86 tools on an ARM64 host. I'll hopefully have that done within the next few days.

I also had issues with compiling RLS due to the use of the old winapi 0.2.8, through mio 0.6.X and tokio, but this should fix itself when tokio fully updates to mio 0.7 instead of mio 0.6.X (see tokio-rs/tokio#1190 )

I noticed the same issue myself when doing an extended build, fortunately rust-analyzer works well on ARM64 when built from source and the rest of the tools (cargo, clippy, rustfmt, rust-src and rustdoc) compile fine, although I haven't tested them yet.

[Stammark]

Regarding psm: rust-lang/stacker#37 (and our PR), so that should be good when the next deps bump happens!

Agreed on link.exe, I'm basically still doing the same thing as you by using the vcvarsx86_arm64 script to set up environment variables.
I have then also been experimenting with hacks on transferring those up into Powershell or MSYS2 for the run-make-fulldeps testsuite, but need to check these with people so that I'm more confident that I'm not breaking anything else in the process

For changes in cc @danielframpton might be interested in hearing what you have in mind, too ;)

Also, massive thank you for the contributions!

[tleasor]

Yep, I'd just seen those fixes on stacker and cc and was about to edit my comment that I'd spoken too soon!

I have then also been experimenting with hacks on transferring those up into Powershell or MSYS2 for the run-make-fulldeps testsuite, but need to check these with people so that I'm more confident that I'm not breaking anything else in the process

That sounds great, I'll have a look into adding support for this target to the release builders.

Also, massive thank you for the contributions!

Thanks for all your help! I'd have been lost without you pointing out that silent assembly error!

[arlosi]

I've been working on getting the cross-build of aarch64 working so we can add it to the CI builders.

rust-lang/cc-rs#524 fixes the failure to run the aarch64 rc.exe on x86_64.

https://reviews.llvm.org/D83022 resolves an issue where the LLVM cross build recurses and tries to do a native build of llvm-nm by allowing the Rust build to specify the path to the native LLVM_NM. This is not in yet. Once it is in, we can backport it to the Rust fork of LLVM.

arlosi/rust@7b73704 has the updates to the Rust build to use the new LLVM_NM option and set the --target flag when using clang-cl (as the Rust CI builders do). I will create the PR for this once the LLVM change is in.

With all that in place, I can cross-build for aarch64-pc-windows-msvc from x86_64-pc-windows-msvc from a normal command prompt with x.py build.