-
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
Add initial CoreCLR compilation support for Apple Silicon #40435
Conversation
Initial draft of CoreCLR runtime native code to supprt Apple Silicon Fixes native runtime compitation issues Draft implementation Testing linited to compilation on Apple Does not fix Arm64 ABI issues Does not fix write no execute issues
Status:
I would appreciate eyes on this. It hasn't been tested yet, but anything we find in code review will simplify bring-up. /cc @tommcdon @JulieLeeMSFT @mangod9 @noahfalk I think this unblocks the JIT team. |
.long 0x04000000 // DWARF | ||
.quad 0 | ||
.quad 0 | ||
#endif |
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 code wasn't quite right. The value for arm64 dwarf is 0x03000000. However even with that fixed the linker was reporting compact unwind errors.
The comments in the Apple compact unwind header suggests the linker will no longer attempt to create compact unwind entries from dwarf tables. Specifically because they found it was too fragile.
I chose to remove this so that the linker was forced to use the dwarf unwind info for these hand coded assembly files.
w/o this change the linker reportes errors related to overlapping __compact_unwind entries as well as corrupt size.
IMHO this seems reasonable....
nice progress @sdmaclea. Great that things are now building. |
I have started a new Priority1 test run on Apple Silicon using tests and runtime built on This should be really close to passing CI. We should be able to merge this soon. The W^X code is known to be preliminary. We intend to refactor in a later PR for
@janvorli Can you please take another look? |
if(convert) | ||
{ | ||
int nsize; | ||
LPSTR newBuff = 0; | ||
nsize = WideCharToMultiByte(CP_ACP, 0,(LPCWSTR)buffer, count, 0, 0, 0, 0); | ||
if (!nsize) | ||
{ | ||
if (count == 0) |
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 still wonder why this occurs for arm64 OSX only and it was fine before.
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 don't remember the test which caught this issue. I looked at the call stack briefly and it looked like a bogus failure to me. This looked like the right fix.
I opened #42954. To investigate this further when we have more capacity for testing on Apple Silicon.
// TBD // Inject the activation only if the thread doesn't have a pending hardware exception | ||
// Inject the activation only if the last ESR.EC was an SVC and therefore the thread doesn't have | ||
// a pending hardware exception | ||
if ((ExceptionState.__esr >> 26) == 0x15) |
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.
Can you please make these named constants or defines to make it clear?
E.g. ESR_EC_SHIFT for the 26 and EC_SVC for 0x15 or something like that.
@@ -3312,6 +3312,10 @@ DWORD_PTR ExceptionTracker::CallHandler( | |||
break; | |||
} | |||
|
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.
It is not clear to me why we need it here.
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 guess it is related to the MakeCallbacksRelatedToHandler()
call below which can call managed code. I am not sure why I didn't place it above the MakeCallbacksRelatedToHandler()
call above, but perhaps we simply didn't have coverage of that case.
It is probably not the right place to put this ultimately, but it is related to the arbitrary nature of the current PAL_JITWriteEnable(*)
placement.
I would suggest leaving this to be cleaned up by #41124
@@ -3948,6 +3952,10 @@ void ExceptionTracker::ResumeExecution( | |||
EH_LOG((LL_INFO100, "resuming execution at 0x%p\n", GetIP(pContextRecord))); | |||
EH_LOG((LL_INFO100, "^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n")); | |||
|
|||
#if defined(HOST_OSX) && defined(HOST_ARM64) |
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.
And I would like to understand why we need it here either.
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 think this might have been added to fix a case where we were trying to JIT a method which didn't exist (probably a dynamic method builder test). Effectively the pre*stub threw an exception and the exception handler required us to return to managed code in the managed exception handler.
So this too is introduced by the ad-hoc placement of the PAL_JITWriteEnable(*)
calls.
I would suggest leaving this to be cleaned up by #41124.
src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/pal_ssl.c
Outdated
Show resolved
Hide resolved
@janvorli I believe I have addressed your comments either directly or by opening issues to be solved later. |
@janvorli The previous commit was green. The most recent commit doesn't touch code currently compiled in CI. |
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 current state LGTM modulo the two comments. But I'd like to get a review of @jkotas now that the change is final.
int main() | ||
{ | ||
int ret; | ||
ret = clock_gettime_nsec_np(CLOCK_UPTIME_RAW); |
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.
Just curious - what was wrong with mach_absolute_time
?
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.
It doesn't exist on aarch64 and Apple doc for mach_absolute_time recommends to replace it with clock_gettime_nsec_np
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.
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 have noticed that HAVE_MACH_ABSOLUTE_TIME
is still used under libraries. Do we need to fix it there as well?
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.
Hmm, the strange thing is that libraries compile for arm64 with it just fine. So maybe the failure due to which I've modified the usage of mach_absolute_time to clock_gettime_nsec_np was something temporary in the middle of the fixes I was making. Anyways, the change is good since the mach_absolute_time is deprecated, so we should change it in the libraries too.
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.
Ok, opened #43320
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.
LGMT
Add initial CoreCLR compilation support for Apple Silicon
Initial draft of CoreCLR runtime native code to support Apple Silicon
Fixes native runtime compilation issues
Draft implementation
Testing limited to compilation on Apple
Does not fix Arm64 ABI issues
Does notPrototypes fix write no execute issuesFixes #40149