richlander
commented
3 years ago We're intending on releasing Apple M1 support (native and R2) starting with .NET 6.0 Preview 1 (first half of February). There will almost certainly be issues and feature gaps in Preview 1. Support will get better with each preview. For example, Preview 1 will have only native SOS-style debugging support and we intend to add managed Visual Studio-style debugging with Preview 3.
Our current thinking is to backport R2 support to .NET 5.0 and .NET Core 3.1, and that native M1 support will be .NET 6.0 only. The change to support native is quite significant, and we don't see a good cost/risk/benefit tradeoff.
zwarich
sdmaclea
janvorli
nixxholas
ilushka85
lemonmojo
DruSatori
GiorgioG
sandreenko
merken
mcoolidge
peterprice
danwalmsley
matthewbluezyoncom
wocar
Apple has announced plans to transition its Mac hardware line to a new Arm64-based chip that they refer to as “Apple Silicon”.
Initial .NET support will be through .NET running on the Rosetta 2 emulator. Longer term native support for Apple Silicon is planned for .NET 6.
While it is hoped that Rosetta 2 emulation will just work, the .NET runtime is complicated and real issues will make this a non-trivial task.
Current known issues
[x] Apple Silicon uses a 16K memory page size. The .NET 5 stack probe code doesn't handle this yet. #45226. Per Apple this only affects the DTK and is fixed on M1 Silicon. Edit: I've verified that on real M1 device, the page size is 4K and the related issue doesn't occur.
[x] Rosetta 2 emulation crashes with a fatal failure when calling with
thread_get_statex86_FLOAT_STATE64. This is because the emulator does not emulate AVX support, but the function should simply return an error. Edit: This is fixed in the macOS 11.2 beta release.[x] Rosetta 2 emulation doesn't populate
exceptionState.__trapnofor other kernel entry than hardware exceptions (for example for syscalls). This means we fail to inject code necessary for garbage collection and sometimes deadlock. Edit: This is at least partially fixed in the macOS 11.2 beta release, but I can still see hangs during .NET runtime / tests managed parts compilation. It is being investigated at the Apple side.[ ]
With #45226 & https://github.com/janvorli/runtime/commit/aee81acd99b9c0e6a406bad3b98c278669c7cc67 19 runtime tests are failing under Rosetta 2 emulation which pass on macOS native x64All the coreclr Pri 1 tests are now passing except two tests (mentioned in the comments below) that are failing with:assertion failed: GPR thread_set_state is unsupported while in sa_tramp. (ThreadContextRegisterState.cpp:1250 thread_set_state_gpr_64)[x] Debugging using VS Code doesn't work. It was partially fixed in the macOS 11.2 beta release, now it is possible to successfully run an application under the debugger and break on a breakpoint. But attempt to single step or continue from that state still fails. It is caused by iret instruction emulation that doesn't honor the trace flag. Edit: This is fixed in macOS 11.2 beta 2
[x] New issue in macOS 11.2 beta - dotnet build and posibly other .NET applications often fail with
assertion failed [abi_info.u.translated_code.instruction_extents.kind == InstructionOffsetKind::Syscall]: on sigreturn exit path but instruction isn't marked as a syscall (ThreadContextRegisterState.cpp:381 x86_gpr_state_from_arm_state)Edit: This is fixed in macOS 11.2 beta 2