Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Epic: Support Apple Silicon #43313

Closed
23 of 31 tasks
sdmaclea opened this issue Oct 12, 2020 · 79 comments
Closed
23 of 31 tasks

Epic: Support Apple Silicon #43313

sdmaclea opened this issue Oct 12, 2020 · 79 comments
Labels
arch-arm64 area-Meta os-macos-bigsur (macOS11) tracking This issue is tracking the completion of other related issues.
Milestone

Comments

@sdmaclea
Copy link
Contributor

sdmaclea commented Oct 12, 2020

Apple has announced plans to transition its Mac hardware line to a new Arm64-based chip that they refer to as “Apple Silicon”. This epic tracks the high level status of the milestones required to ship this feature in .NET 6.

.NET 6 will include new runtime id -- osx-arm64 -- for targeting this hardware. It refers to the macOS operating system running on Apple Silicon devices.

.NET Rosetta Emulation

.NET 6 - CoreCLR Native

Functionality

  • Support compilation targeting osx-arm64
  • Modify code generation to support osx-arm64 security features
  • Modify code generation to support osx-arm64 interop with native libraries

Testing

  • Apple Silicon Prototype hardware available
  • Manual testing of basic inner and outer loop tests
  • Apple commercially shipping arm64 macos devices
  • CI/CD Testing enabled
  • CI/CD Stress testing enabled

Stability

  • Basic tests passing rate > 99%
  • Stress tests passing rate > 99%
  • All tests passing rate > 99.9%

Availability

Details

See Enable .NET Core on Apple Silicon for the full set of related PRs and issues.

.NET 6 - Mono

Functionality

  • Support compilation targeting osx-arm64
  • Modify code generation to support osx-arm64 security features
  • Modify code generation to support osx-arm64 interop with native libraries

Testing

  • Apple Silicon Prototype hardware available
  • Manual testing of basic inner and outer loop tests
  • Apple commercially shipping arm64 macos devices
  • CI/CD Testing enabled
  • CI/CD Stress testing enabled

Stability

  • Basic tests passing rate > 99%
  • Stress tests passing rate > 99%
  • All tests passing rate > 99.9%

Availability

  • Runtime nightly builds available
  • .NET 6 preview available
  • .NET 6 release available

/cc @richlander @mangod9 @janvorli @JulieLeeMSFT @sandreenko @tommcdon @steveisok @directhex @akoeplinger @jeffschwMSFT

@sdmaclea sdmaclea added Epic Groups multiple user stories. Can be grouped under a theme. arch-arm64 area-Meta os-macos-bigsur (macOS11) labels Oct 12, 2020
@sdmaclea sdmaclea added this to the 6.0.0 milestone Oct 12, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Oct 12, 2020
@warrenrumak
Copy link

warrenrumak commented Oct 12, 2020

By the time .NET 6 is released, it will have been more than five years since Apple renamed this operating system to "macOS". It's not called "OS X" any more. If it can be done correctly in TFMs, it can be done correctly in RIDs.

@richlander
Copy link
Member

Yup. Please file an issue @warrenrumak.

@lambdageek
Copy link
Member

For Mono, I think the work item "Modify code generation to support osx-arm64 interop with native libraries" is done in the sense that the ABI is the same as ios which we already support. Is that right, @vargaz ?

@eschwieb
Copy link

For Mono, I think the work item "Modify code generation to support osx-arm64 interop with native libraries" is done in the sense that the ABI is the same as ios which we already support. Is that right, @vargaz ?

Indeed. Apple has confirmed to me that the Apple silicon Mac ABI is precisely the same as their iOS ARM ABI.

@vargaz
Copy link
Contributor

vargaz commented Oct 26, 2020

Yes, we don't support the arm64e stuff, but otherwise mono works on osx/arm64, both in the old mono repo and in dotnet/runtime. Couldn't run test suites because the sdk tools were hanging.

@sdmaclea
Copy link
Contributor Author

sdmaclea commented Oct 26, 2020

@jeffschwMSFT I'm not sure if this is supposed to be a team epic. This was created with @richlander. I thought it was supposed to be a customer facing epic.

@jeffschwMSFT
Copy link
Member

This feels like the right level of scope to me. Thank you for helping to keep our progress tracked and visible.

@ilushka85
Copy link

Given how quick things are coming for true arm64 for apple in 6.0 perhaps it makes sense to make the changes for 5.0 rather than trying to make it work on rosetta 2?

@richlander
Copy link
Member

The belief is that people will want a supported .NET product on Apple Silicon before November 2021. That's why we are enabling 5.0 in R2 as well as enabling 6.0 to run natively. Also, there will be scenarios where 6.0 will need to run in R2 as well, so we might as well get that scenario working with 5.0.

@sdmaclea
Copy link
Contributor Author

@vitek-karas @richlander Roll Forward on Publish??? Better error message???

@taidang1902
Copy link

@taidang1902 Looks like you are trying to publish osx-arm64 targeting .NET Core 3.1. The preview2 SDK will support publishing osx-arm64 for .NET6, but not earlier. You should be able to publish for osx-x64 .NET Core 3.1 and run under Rosetta 2.

That's work for me, thanks @sdmaclea 👍

@vitek-karas
Copy link
Member

@sdmaclea It depends on the result of the discussion in dotnet/designs#182 and the related work items. IN short - this should not happen, so there's little value in improving the error message. It's caused by the current broken state where 6.0 installer overwrites the x64 hostfxr with an arm64-only hostfxr (same for muxer).

@sdmaclea
Copy link
Contributor Author

IN short - this should not happen

@vitek-karas The issue reported above by @taidang1902 is different. It hasn't been discussed in dotnet/designs#182 yet. It would occur even if only the .NET6 Apple Silicon SDK was installed. It occurs when targeting an older runtime for Apple Silicon. Anytime target ramework < .NET6 that error will occur.

@vitek-karas
Copy link
Member

vitek-karas commented Mar 22, 2021

SDK should not allow to build anything for <6 osx-arm64 RID. But that's not what @taidang1902 failure is. That failure is the expected failure right now. The publish command chose 3.1 SDK (I'm guessing, but it's a pretty good guess), so it wants to run it on 3.1. The 6.0 arm64 hostfxr resolves the x64 3.1 framework installed and tries to load hostpolicy from it - and fails (arch mismatch).

If it worked, that command should still fail if the app is targeting 3.1 (and it probably does fail since it won't find the osx-arm64 runtime pack for 3.1).

@sdmaclea
Copy link
Contributor Author

OK. There is a different failure when publishing for osx-arm4 < NET6. Basically the cryptic message in that case is about no suitable AppHost found.

@vitek-karas
Copy link
Member

This would happen for any unsupported RID really - pick any RID which is supported in 6 and not supported in 3.1 and try it on 3.1 - the experience will be the same I'm afraid. But I understand that maybe we want to do better for this case, as it's more likely to happen.

@gnida-rada
Copy link

Is there a plan to have .NET Core 3.1 run on M1/Silicon Macs without Rosetta? Our problem:

  1. Moving to .NET 6 is a significant investment for us that we cannot afford soon.
  2. .NET Core 3.1 runtime sometimes calls dlopen (specifically, dlopen("libssl.x.x.x") in opensslshim.c). And it seems that when .NET runtime runs in Rosetta, dlopen() refuses to open libssl.x.x.dylib with only arm64 architecture.
  3. installing openssl with homebrew installs arm64 only architecture that dlopen() will ignore (see 2 above)
    Thanks!

@iMonZ
Copy link

iMonZ commented Apr 26, 2021

Is there a plan to have .NET Core 3.1 run on M1/Silicon Macs without Rosetta? Our problem:

  1. Moving to .NET 6 is a significant investment for us that we cannot afford soon.
  2. .NET Core 3.1 runtime sometimes calls dlopen (specifically, dlopen("libssl.x.x.x") in opensslshim.c). And it seems that when .NET runtime runs in Rosetta, dlopen() refuses to open libssl.x.x.dylib with only arm64 architecture.
  3. installing openssl with homebrew installs arm64 only architecture that dlopen() will ignore (see 2 above)
    Thanks!

Theoretically it could work but it would be a bad experience for the customer. Same problem with QT.
I would recommend use Rosetta 2 until you can afford upgrading to .NET 6

@sdmaclea
Copy link
Contributor Author

@gnida-rada There is no current plan to support 3.1 natively on Apple Silicon. If this is a significant issue, you should open a separate issue for it, so that it can be discussed in a separate thread.

@mangod9
Copy link
Member

mangod9 commented Jul 19, 2021

Will be closing this user story now. Only remaining issue is the intermittent NRE which we are continuing to investigate. There are some additional bugs which are tracked separately.

@mangod9 mangod9 closed this as completed Jul 19, 2021
@iMonZ
Copy link

iMonZ commented Jul 19, 2021

Will be closing this user story now. Only remaining issue is the intermittent NRE which we are continuing to investigate. There are some additional bugs which are tracked separately.

What’s with renaming osx to macOS?

@mangod9
Copy link
Member

mangod9 commented Jul 19, 2021

What’s with renaming osx to macOS?

Will need to move that to .net 7.

@iMonZ
Copy link

iMonZ commented Jul 19, 2021

What’s with renaming osx to macOS?

Will need to move that to .net 7.

Oh no :(
I hoped this would come to the LTS.
That’s pretty sad
This would complete the new macOS support in the dotNet 6 version

@omajid
Copy link
Member

omajid commented Jul 28, 2021

Hey, @mangod9 do you have a link to the NullReferenceExceptions that you are tracking? I am interested in following that. We are hitting some NREs on non-macOS arm64 platforms as well, which might be the same or a different issue.

@mangod9
Copy link
Member

mangod9 commented Jul 28, 2021

Hi @omajid, here is the tracking issue for that: #51250.

@janvorli
Copy link
Member

@omajid, most of the NullReferenceExceptions ended up being fixed by my change #53510 in preview 6. It was a general ARM64 issue.

@ghost ghost locked as resolved and limited conversation to collaborators Aug 28, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-arm64 area-Meta os-macos-bigsur (macOS11) tracking This issue is tracking the completion of other related issues.
Projects
Archived in project
Development

No branches or pull requests