-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Changes from 18 commits
ca95d4b
35a40f0
387b31b
50eb6f6
cb81686
69fd921
b05ba08
8742268
92a7164
6325ba7
125bed7
817b10c
f44843f
3308493
8b9d0dc
9d73bfa
5244049
59b79b3
d8c7ee0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -60,8 +60,9 @@ public override ObjectData GetData(NodeFactory factory, bool relocsOnly = false) | |
{ | ||
var builder = new ObjectDataBuilder(factory, relocsOnly); | ||
|
||
// These need to be aligned the same as methods because they show up in same contexts | ||
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); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
|
||
builder.AddSymbol(this); | ||
|
||
|
There was a problem hiding this comment.
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?There was a problem hiding this comment.
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 whenalignment < OS_PAGE_SIZE
so I think the change is quite safe.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
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 noazp run
trigger for that pipeline, someone with access will need to trigger it manually.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
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 andGC_PAGE_SIZE != OS_PAGE_SIZE
.