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

[NativeAOT] Initial osx-arm64 bring up #75264

Merged
merged 19 commits into from
Sep 11, 2022
Merged

Conversation

filipnavara
Copy link
Member

@filipnavara filipnavara commented Sep 8, 2022

Depends on dotnet/llvm-project#185.
Fixes #67232
Fixes #64337

Thanks to @am11 @MichalStrehovsky and @jkotas for the help with pushing this forward and analysing all the issues that came up.

@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Sep 8, 2022
@filipnavara filipnavara changed the title [NativeAOT] osx-arm64 bring up [NativeAOT] Initial osx-arm64 bring up Sep 8, 2022
src/coreclr/nativeaot/Runtime/unix/UnwindHelpers.cpp Outdated Show resolved Hide resolved
@@ -633,7 +633,7 @@ void GCToOSInterface::YieldThread(uint32_t switchCount)
static void* VirtualReserveInner(size_t size, size_t alignment, uint32_t flags, uint32_t hugePagesFlag = 0)
{
assert(!(flags & VirtualReserveFlags::WriteWatch) && "WriteWatch not supported on Unix");
if (alignment == 0)
if (alignment < OS_PAGE_SIZE)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrap under #if defined(HOST_ARM64) && defined(TARGET_OSX) && defined(FEATURE_NATIVEAOT) to limit the scope of this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would still like to know why CoreCLR doesn't hit this but I assume that it's because of some GC feature switch (such as FEATURE_MANUALLY_MANAGED_CARD_BUNDLES).

While I can add the #if guards the code would still misbehave fatally when alignment < OS_PAGE_SIZE so I think the change is quite safe.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would still like to know why CoreCLR doesn't hit this

AFAIK gcenv.unix.cpp is only used by CoreCLR when standalone GC is used (i.e. COMPlus_GCName is set to point to a standalone GC instead of the one in coreclr.dll/.so). @mangod9 @dotnet/gc can you have a look at this change?

Copy link
Member

@am11 am11 Sep 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the regular CI pipelines do not use this code. We should trigger gc-standalone pipeline https://dev.azure.com/dnceng/public/_build?definitionId=1017 against this PR to get realistic results (windows arm64 checked failure in that pipeline is preexisting, the rest should be green). AFAIK, there is no azp run trigger for that pipeline, someone with access will need to trigger it manually.

Copy link
Member

@MichalStrehovsky MichalStrehovsky Sep 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, there is no azp run trigger for that pipeline, someone with access will need to trigger it manually.

I tried to trigger it but it's complaining about the pool. It doesn't look like the gc-standalone pipeline ran for a week or so. It coincides with the pool changes. Cc @dotnet/gc.

The interesting thing about the gc-standalone pipeline is that it doesn't test mac at all. So if there was a arm64 macOS issue with standalone GC, we wouldn't even know it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if there was a arm64 macOS issue with standalone GC, we wouldn't even know it.

This change as written is not specific to arm64 macOS, other platforms can break. My original commit was am11@45f3a48, but it was recreated without the guard which has potential to break existing code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The specific call with the "invalid" alignment parameter is macOS arm64 specific though. It happens because of 16Kb page sizes and GC_PAGE_SIZE != OS_PAGE_SIZE.

src/coreclr/nativeaot/Runtime/CommonMacros.h Outdated Show resolved Hide resolved
@filipnavara
Copy link
Member Author

The last two commits unblock the library tests. It seems to work quite well, so we may try to get a full run on the CI once this is merged.

builder.RequireInitialAlignment(factory.Target.MinimumFunctionAlignment);
// These need to be aligned the same as method pointers because they show up in same contexts
// (macOS ARM64 has even stricter alignment requirement for the linker, so round up to pointer size)
builder.RequireInitialAlignment(factory.Target.PointerSize);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is actually hell to diagnose because it produces no error but causes corruption when linking. If absolute relocation of a symbols is 4-byte aligned and spans between two pages in the executable then only the lower part of the relocation is written correctly into the final executable.

This was the root cause of the intermittent problem I've hit earlier.

@filipnavara
Copy link
Member Author

filipnavara commented Sep 9, 2022

I ran the library test locally and the results look promising:

/Users/filipnavara/Projects/runtime/eng/testing/tests.targets(181,5): error : One or more tests failed while running tests from 'System.Console.Tests'. [/Users/filipnavara/Projects/runtime/src/libraries/System.Console/tests/System.Console.Tests.csproj]
/Users/filipnavara/Projects/runtime/eng/testing/tests.targets(181,5): error : One or more tests failed while running tests from 'System.Diagnostics.Process.Tests'. [/Users/filipnavara/Projects/runtime/src/libraries/System.Diagnostics.Process/tests/System.Diagnostics.Process.Tests.csproj]
/Users/filipnavara/Projects/runtime/eng/testing/tests.targets(181,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.OpenSsl.Tests'. [/Users/filipnavara/Projects/runtime/src/libraries/System.Security.Cryptography.OpenSsl/tests/System.Security.Cryptography.OpenSsl.Tests.csproj]
/Users/filipnavara/Projects/runtime/eng/testing/tests.targets(181,5): error : One or more tests failed while running tests from 'System.Runtime.Extensions.Tests'. [/Users/filipnavara/Projects/runtime/src/libraries/System.Runtime.Extensions/tests/System.Runtime.Extensions.Tests.csproj]

Specifically, System.Runtime.Extensions.Tests has single failure related to macOS Ventura (#75371):

  [FAIL] System.Tests.EnvironmentTests.OSVersion_ValidVersion_OSX
  Assert.Contains() Failure
  Not found: 13
  In value:  osx-arm64
     at System.Tests.EnvironmentTests.OSVersion_ValidVersion_OSX() + 0x68
     at System.Runtime.Extensions!<BaseAddress>+0x1256b74
     at System.Runtime.RawCalliHelper.Call(IntPtr, Void*, Byte&, Byte&, Void*) + 0x40
     at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x27c

System.Security.Cryptography.OpenSsl.Tests fails because of missing OpenSSL library (expected):

  Running assembly:System.Security.Cryptography.OpenSsl.Tests, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
  No usable version of libssl was found
  /Users/filipnavara/Projects/runtime/artifacts/bin/System.Security.Cryptography.OpenSsl.Tests/Debug/net7.0-unix/publish/RunTests.sh: line 168: 63790 Abort trap: 6           ./System.Security.Cryptography.OpenSsl.Tests -notrait category=OuterLoop -notrait category=failing -xml testResults.xml $RSP_FILE
  ~/Projects/runtime/src/libraries/System.Security.Cryptography.OpenSsl/tests
  ----- end Fri Sep 9 19:49:15 CEST 2022 ----- exit code 134 ----------------------------------------------------------
  exit code 134 means SIGABRT Abort. Managed or native assert, or runtime check such as heap corruption, caused call to abort(). Core dumped.
  ulimit -c value: 0
/Users/filipnavara/Projects/runtime/eng/testing/tests.targets(181,5): error : One or more tests failed while running tests from 'System.Security.Cryptography.OpenSsl.Tests'. [/Users/filipnavara/Projects/runtime/src/libraries/System.Security.Cryptography.OpenSsl/tests/System.Security.Cryptography.OpenSsl.Tests.csproj]

System.Diagnostics.Process.Tests has one failure (flaky):

  [FAIL] System.Diagnostics.Tests.ProcessTests.GetProcessesByName_ProcessName_ReturnsExpected
  Assert.All() Failure: 1 out of 2 items in the collection did not pass.
  [0]: Item: System.Diagnostics.Process (System.Diagnost)
       Xunit.Sdk.EqualException: Assert.Equal() Failure
       Expected: 2022-09-09T19:49:07.9700180+02:00
       Actual:   2022-09-09T19:49:07.9916470+02:00
          at Xunit.Assert.Equal[T](T expected, T actual, IEqualityComparer`1 comparer) + 0x16c
          at Xunit.Assert.Equal[T](T expected, T actual) + 0x40
          at System.Diagnostics.Tests.ProcessTests.<>c__DisplayClass90_0.<GetProcessesByName_ProcessName_ReturnsExpected>b__3(Process process) + 0x40
          at Xunit.Assert.<>c__DisplayClass11_0`1.<All>b__0(T item, Int32 index) + 0x3c
          at Xunit.Assert.All[T](IEnumerable`1 collection, Action`2 action) + 0xf0
     at System.Diagnostics.Tests.ProcessTests.GetProcessesByName_ProcessName_ReturnsExpected() + 0x350
     at System.Diagnostics.Process!<BaseAddress>+0x11234f4
     at System.Runtime.RawCalliHelper.Call(IntPtr, Void*, Byte&, Byte&, Void*) + 0x40
     at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x27c

System.Console.Tests has couple of failures related to Remote Executor (missing RemoteExecutor guard):

[FAIL] Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(envVar: null)
  System.PlatformNotSupportedException : RemoteExecutor is not supported on this platform.
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(MethodInfo method, String[] args, RemoteInvokeOptions options, Boolean pasteArguments) + 0xb8
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(Action`1 method, String arg, RemoteInvokeOptions options) + 0x6c
     at Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(String envVar) + 0x174
     at System.Console!<BaseAddress>+0x10c0ad8
     at System.Runtime.RawCalliHelper.Call(IntPtr, Void*, Byte&, Byte&, Void*) + 0x40
     at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x358
  [FAIL] Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(envVar: "1")
  System.PlatformNotSupportedException : RemoteExecutor is not supported on this platform.
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(MethodInfo method, String[] args, RemoteInvokeOptions options, Boolean pasteArguments) + 0xb8
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(Action`1 method, String arg, RemoteInvokeOptions options) + 0x6c
     at Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(String envVar) + 0x174
     at System.Console!<BaseAddress>+0x10c0ad8
     at System.Runtime.RawCalliHelper.Call(IntPtr, Void*, Byte&, Byte&, Void*) + 0x40
     at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x358
  [FAIL] Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(envVar: "true")
  System.PlatformNotSupportedException : RemoteExecutor is not supported on this platform.
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(MethodInfo method, String[] args, RemoteInvokeOptions options, Boolean pasteArguments) + 0xb8
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(Action`1 method, String arg, RemoteInvokeOptions options) + 0x6c
     at Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(String envVar) + 0x174
     at System.Console!<BaseAddress>+0x10c0ad8
     at System.Runtime.RawCalliHelper.Call(IntPtr, Void*, Byte&, Byte&, Void*) + 0x40
     at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x358
  [FAIL] Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(envVar: "tRuE")
  System.PlatformNotSupportedException : RemoteExecutor is not supported on this platform.
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(MethodInfo method, String[] args, RemoteInvokeOptions options, Boolean pasteArguments) + 0xb8
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(Action`1 method, String arg, RemoteInvokeOptions options) + 0x6c
     at Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(String envVar) + 0x174
     at System.Console!<BaseAddress>+0x10c0ad8
     at System.Runtime.RawCalliHelper.Call(IntPtr, Void*, Byte&, Byte&, Void*) + 0x40
     at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x358
  [FAIL] Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(envVar: "0")
  System.PlatformNotSupportedException : RemoteExecutor is not supported on this platform.
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(MethodInfo method, String[] args, RemoteInvokeOptions options, Boolean pasteArguments) + 0xb8
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(Action`1 method, String arg, RemoteInvokeOptions options) + 0x6c
     at Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(String envVar) + 0x174
     at System.Console!<BaseAddress>+0x10c0ad8
     at System.Runtime.RawCalliHelper.Call(IntPtr, Void*, Byte&, Byte&, Void*) + 0x40
     at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x358
  [FAIL] Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(envVar: "false")
  System.PlatformNotSupportedException : RemoteExecutor is not supported on this platform.
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(MethodInfo method, String[] args, RemoteInvokeOptions options, Boolean pasteArguments) + 0xb8
     at Microsoft.DotNet.RemoteExecutor.RemoteExecutor.Invoke(Action`1 method, String arg, RemoteInvokeOptions options) + 0x6c
     at Color.RedirectedOutput_EnvVarSet_EmitsAnsiCodes(String envVar) + 0x174
     at System.Console!<BaseAddress>+0x10c0ad8
     at System.Runtime.RawCalliHelper.Call(IntPtr, Void*, Byte&, Byte&, Void*) + 0x40
     at System.Reflection.DynamicInvokeInfo.Invoke(Object, IntPtr, Object[], BinderBundle, Boolean) + 0x358

@am11
Copy link
Member

am11 commented Sep 10, 2022

We can enable CI testing in the next PR (after this and #75055 are merged).

Thanks a lot @filipnavara for pushing the boundaries! 🐎

@filipnavara
Copy link
Member Author

Rebased after #75393 merge.

@jkotas jkotas merged commit cb6fb60 into dotnet:main Sep 11, 2022
@jkotas
Copy link
Member

jkotas commented Sep 11, 2022

@filipnavara Thank you!

@filipnavara filipnavara deleted the nativeaot-m1 branch September 11, 2022 19:05
@teo-tsirpanis teo-tsirpanis added this to the 8.0.0 milestone Sep 11, 2022
@tgjones
Copy link
Contributor

tgjones commented Sep 12, 2022

@filipnavara thank you for this!

A general question: is there an intention to backport this to 7.0, or is it strictly an 8.0 thing?

@filipnavara
Copy link
Member Author

A general question: is there an intention to backport this to 7.0, or is it strictly an 8.0 thing?

It missed the 7.0 deadline by a lot. However, it is possible to consume the ILCompiler package from NuGet so I think the realistic goal is to make it possible to use that with .NET 7 SDK.

@jkotas
Copy link
Member

jkotas commented Sep 12, 2022

The instructions for using daily build packages are at https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/compiling.md#using-daily-builds

MichalStrehovsky added a commit that referenced this pull request Sep 13, 2022
The alignment changed in #75264, but it's important this is always at least MinimumFunctionAlignment no matter the platform because that's how we distinguish fat pointers from real pointers. This assert is obviously true on every platform we support right now.
MichalStrehovsky added a commit that referenced this pull request Sep 14, 2022
The alignment changed in #75264, but it's important this is always at least MinimumFunctionAlignment no matter the platform because that's how we distinguish fat pointers from real pointers. This assert is obviously true on every platform we support right now.
@ghost ghost locked as resolved and limited conversation to collaborators Oct 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-NativeAOT-coreclr community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Reloc failures with NativeAOT on Apple Silicon NativeAOT for osx-arm64
7 participants