Ensure building dotnet/runtime works on Windows ARM64

[adamsitnik]

Hello everyone!

Some time ago I've received my very first ARM64 machine - Surface Pro X. I was very happy about it as I was hoping that it would make ARM64 performance investigations easier for me.

Recently the right opportunity has arisen - I've identified a few ARM64-specific regressions (#41699, #41704, #41706) and decided to prepare a simple workshop where I would explain how to: run benchmarks, profile, and get the disassembly on ARM64. To make sure that everyone on the team can solve simple ARM64-specific performance issues.

Since it's currently impossible to install Linux on Surface Pro X and our performance tooling is more mature on Windows, I decided to prepare a Windows workshop first. I did not want to use WSL as it adds another layer of abstraction and none of our customers run .NET Core apps via WSL in production.

I've tried running some BenchmarkDotNet benchmarks and using PerfView to profile them. Everything worked perfectly fine.

As we all know, after a performance bottleneck is identified, the next step is to apply a fix, rebuild the product and run the benchmarks against the modified build.

And this is where I've failed.

After running a very simple command:

build.cmd -c Release -arch arm64

The build got stuck after printing a few lines to the output. It turned out to be a known issue: #38902. I remembered that @eiriktsarpalis mentioned to me a while ago that the new SDK should contain a fix and that @ViktorHofer send an email about updating the SDK version just a few days ago. So I've pulled Viktor's PR: #41947 and it solved this particular problem.

Then I've faced another problem, read the docs about Windows ARM requirements and installed missing VS components (this doc is great 👍 )

Another problem was gone, but a new one has arisen:

    This version of C:\Projects\runtime\artifacts\bin\coreclr\Windows_NT.arm64.Release\x64\dactabletools\InjectResource.exe is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher.
  C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): error MSB6006: "cmd.exe" exited with code 216. [C:\Projects\runtime\artifacts\obj\coreclr\Windows_NT.arm64.Release\src\dlls\mscoree\coreclr\inject_debug_resources.vcxproj]
  BUILD: Error: native component build failed. Refer to the build log files for details.

The full log is available here

Here I decided to stop and asked @eiriktsarpalis for help. Eirik told me that from what he knows building the runtime repo on Windows ARM64 is currently not supported and the only workaround is to cross-build the runtime on x64 machine and copy the binaries to the ARM machine... Or switch to WSL2 and build it for Linux as it works fine.

Building a product on a different machine and copying it over to my Surface box hurts my productivity a lot. I am not the only person who got Surface Pro X. I imagine that other team members (@pgovind @carlossanlop @eiriktsarpalis @kunalspathak) would also like to have the possibility to just build the product locally, attach the debugger, run the tests, etc. Just get the work done smoothly and move to the next task.

@ericstj @danmosemsft Is there any chance for improving the developer experience on Windows ARM64?

Tagging subscribers to this area: @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[ViktorHofer]

cc @mikem8361 @jkoritzinsky for the dactabletools issue

[danmoseley]

building the runtime repo on Windows ARM64 is currently not supported

Does this mean we have decided we won't get it to work? Or that we haven't yet got it to work? It would be nice to continue to understand what blocks it - assuming that we do support the shipping SDK on this OS.

[eiriktsarpalis]

Does this mean we have decided we won't get it to work? Or that we haven't yet got it to work?

I think it's probably the latter. It would be nice if we could try to get a CI job running the build on ARM64 natively.

[danmoseley]

cc @ericstj it would be good to have this on our infra backlog. Maybe it's one of the tasks for the next couple months.

[jkoritzinsky]

My guess here is that the build-runtime.cmd script still tries to do a cross-build for arm64 even when building on an arm64 machine. So it's erroring out when trying to run the x64 tools built earlier on the arm64 binaries since Windows 10 ARM64 only has an x86 emulator, not x64.

[ericstj]

It would be nice to continue to understand what blocks it

Reading through @adamsitnik's issues it's just a mix of product bugs, which got fixed, then repo bugs in individual components. Those should just get filed against the component owners and fixed.

Sure someone on the infra team can drive this. Once we get clean we should add a CI leg (if hardware is available) to protect it.