-
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 support for building CoreCLR for iOS/tvOS simulator #98127
Conversation
Tagging subscribers to 'os-ios': @steveisok, @akoeplinger, @kotlarmilos Issue DetailsBuild instructions:
Additional work outside of dotnet/runtime:
|
For my own curiosity, will CoreCLR iOS apps be possible to be shipped in the third-party app stores that will come to the EU? |
Tagging subscribers to this area: @hoyosjs Issue DetailsBuild instructions:
Additional work outside of dotnet/runtime:
|
@@ -34,6 +34,7 @@ | |||
static const Entry s_sysNative[] = | |||
{ | |||
DllImportEntry(SystemNative_FStat) | |||
#if !defined(TARGET_APPLE) || defined(TARGET_OSX) |
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.
src/native/libs are shared with Mono. How does this work on iOS - why are these changes not needed for Mono/iOS?
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 file is used only for the static entrypoint resolution in apphost. Technically we would not need it here either if I removed the (unused) apphost build.
Probably not. I was hoping that there would be a change to allow deployment to your own device for debugging purposes, but you still need a restricted entitlement (JIT) for that and Apple won’t let you get it for signing. |
Unfortunately, the debugger doesn't work yet (CORDBG_E_DEBUG_COMPONENT_MISSING). I think I didn't compile all the components. I'll drop the tvOS part with next rebase, it's not polished... |
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
mono_ios_runtime_init (void) | ||
{ | ||
#if INVARIANT_GLOBALIZATION | ||
setenv ("DOTNET_SYSTEM_GLOBALIZATION_INVARIANT", "1", TRUE); |
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.
Would it work if these were passed via runtime properties? It feels wrong to pollute the process env. variable space like 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.
FWIW this is preexisting code from
runtime/src/tasks/AppleAppBuilder/Templates/runtime.m
Lines 260 to 262 in 5161ccd
#if INVARIANT_GLOBALIZATION | |
setenv ("DOTNET_SYSTEM_GLOBALIZATION_INVARIANT", "1", TRUE); | |
#endif |
I didn't really think it matters when the AppleAppBuilder was used only for tests and samples. However, it got productized as part of shared library building tooling, so maybe we should revisit 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.
yes this could use runtimeconfig now, I think this was added way back when we didn't have support for parsing it and this was just used for tests
} | ||
|
||
void | ||
mono_ios_runtime_init (void) |
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.
Nit: maybe once this is merged, we should followup with some naming cleanup in the samples and rename this to just ios_runtime_init
...
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.
Thanks, looks great! Could we add some test coverage to this PR? Is it possible to enable functional tests?
Build the runtime pack and tools with | ||
|
||
``` | ||
./build.sh clr+clr.runtime+libs+packs -os [iossimulator/tvossimulator/maccatalyst] -arch [x64/arm64] -cross -c Release |
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.
Is it possible to JIT on arm64 simulators?
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.
Technically yes. You need to call the one API to enable it which is not allowed in headers. I would not do that in production, but I think it's okay for local debugging.
#if !HAVE_MACH_EXCEPTIONS | ||
#if defined(TARGET_TVOS) | ||
|
||
static bool SwitchStackAndExecuteHandler(int code, siginfo_t *siginfo, void *context, size_t sp) |
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.
Why is this tvOS-specific?
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.
tvOS arbitrarily lacks some of the Mach APIs. I was planning to rebase and drop the tvOS part for now.
@@ -588,7 +588,7 @@ namespace CorUnix | |||
m_pNext = pNext; | |||
}; | |||
|
|||
#if !HAVE_MACH_EXCEPTIONS | |||
#if !HAVE_MACH_EXCEPTIONS && !defined(TARGET_TVOS) |
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.
What scenarios would apply here, if not tvOS-related?
@@ -190,10 +190,10 @@ private static string SetArch(string arch) | |||
string? diagnosticPorts, | |||
IEnumerable<string> runtimeComponents, | |||
string? nativeMainSource = null, | |||
bool useNativeAOTRuntime = false, | |||
TargetRuntime targetRuntime = TargetRuntime.MonoVM, |
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.
Thanks for introducing TargetRuntime
enum.
Can we integrate this into the official build pipeline and run a functional test in |
Sorry for not caring enough about this PR. I hope to give it some attention next week.
I'll check what would it take but the YAML pipelines are not exactly my strength. |
…am.csproj -c Release /p:TargetOS=iossimulator /p:TargetArchitecture=arm64 /p:AppleAppBuilderRuntime=CoreCLR /p:DeployAndRun=true /p:UseMonoRuntime=false /p:RunAOTCompilation=false /p:MonoForceInterpreter=false
Co-authored-by: Adeel Mujahid <[email protected]>
eec0c41
to
8d293e1
Compare
I'll rebase the PR again. I don't have much time to work on this at the moment. Last time I tried to get the debugger working. First problem is that the app gets native DAC instead of the cross-build DAC and the cross-built one is not signed as part of the build process. I managed to manually copy the right binaries into the deployed app bundle. I proceeded to test with the Samsung .NET Debugger so I can get more info about the errors. The next thing that failed was opening the debug pipe (timeout). Unfortunately, I didn't take notes at that point, so I don't have more details to share. |
I wonder if we should get the straightforward changes like TARGET_OSX -> TARGET_APPLE extracted to a separate PR? |
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
Build instructions:
./build.sh clr+clr.runtime+libs+packs -os [iossimulator/tvossimulator/maccatalyst] -arch [x64/arm64] -cross -c Release
./dotnet.sh publish src/mono/sample/iOS/Program.csproj -c Release /p:TargetOS=iossimulator /p:TargetArchitecture=arm64 /p:DeployAndRun=true /p:UseMonoRuntime=false /p:RunAOTCompilation=false /p:MonoForceInterpreter=false
Additional work outside of dotnet/runtime:
KnownRuntimeFramework
to use thisObligatory screenshot: