[NativeAOT] Properly implement targeting iOS-like platforms rather than pretending to be macOS

[ivanpovazan]

Description

Initial support for targeting iOS-like platforms with NativeAOT introduced with: #81476 uses a workaround in JIT interface:

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Line 3066 in 8f19f4e

target.IsOSXLike ? CORINFO_OS.CORINFO_MACOS : CORINFO_OS.CORINFO_UNIX;

hardwiring the compilation as if the target platform is macOS which also brings along corresponding implications on the native side.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Initial support for targeting iOS-like platforms with NativeAOT introduced with: #81476 uses a workaround in JIT interface:

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Line 3066 in 8f19f4e

target.IsOSXLike ? CORINFO_OS.CORINFO_MACOS : CORINFO_OS.CORINFO_UNIX;

hardwiring the compilation as if the target platform is macOS which also brings along corresponding implications on the native side.

Author:	ivanpovazan
Assignees:	-
Labels:	os-ios, area-NativeAOT-coreclr
Milestone:	8.0.0

[ivanpovazan]

/cc: @akoeplinger

[MichalStrehovsky]

What problem is this causing? If there are ABI differences (that this bit controls in the JIT), I'd expect we wouldn't be able to run a MAUI app.

[jkotas]

Is this issue just about renaming macOS to OSXLike in the JIT and JIT/EE interface?

[filipnavara]

Does the flag control the ABI only, or can it have effect on something like the minimum expected architecture baseline? (which is different between M1 ARM and Axx ARM).

[MichalStrehovsky]

Instruction sets are configured here; the JIT doesn't decide this:

runtime/src/coreclr/tools/Common/InstructionSetHelpers.cs

Lines 26 to 34 in e141ce4

	if (targetOS == TargetOS.OSX)
	{
	// For osx-arm64 we know that apple-m1 is a baseline
	instructionSetSupportBuilder.AddSupportedInstructionSet("apple-m1");
	}
	else
	{
	instructionSetSupportBuilder.AddSupportedInstructionSet("neon"); // Lower baselines included by implication
	}

[ivanpovazan]

@akoeplinger could you please add more context?

[akoeplinger]

Is this issue just about renaming macOS to OSXLike in the JIT and JIT/EE interface?

That is an option, but when I initially did the iOS changes for NativeAOT I tried to add a new platform CORINFO_IOS etc but then hit some issues with the consistency checks here:

runtime/src/coreclr/jit/compiler.cpp

Lines 5852 to 5855 in 0570583

	// compMatchedVM is set to true if both CPU/ABI and OS are matching the execution engine requirements
	//
	// Do we have a matched VM? Or are we "abusing" the VM to help us do JIT work (such as using an x86 native VM
	// with an ARM-targeting "altjit").

Back then I didn't have time to investigate further so we went with pretending to target macOS for iOS.

[MichalStrehovsky]

Back then I didn't have time to investigate further so we went with pretending to target macOS for iOS.

The question is if there's anything different for iOS that we would need a new value to distinguish it in RyuJIT. We distinguish it as TargetOS in the C# part of the compiler, but only because there's one spot in the LLVM object writer that puts this into the object file (99.9% of the compiler doesn't see it as a different OS). Is there a part of RyuJIT that needs to know?

[akoeplinger]

As far as I can see the JIT would be fine with a generic "Apple" value, except for the compatibility checks. E.g. this one:

runtime/src/coreclr/jit/compiler.cpp

Lines 5874 to 5876 in 0570583

	// MacOS x64 uses the Unix jit variant in crossgen2, not a special jit
	info.compMatchedVM =
	info.compMatchedVM && ((eeInfo->osType == CORINFO_UNIX) || (eeInfo->osType == CORINFO_MACOS));

I assume we also use the Unix jit variant for iOS x64 (Simulator) today so presumably it works fine.

If you think that we don't need this distinction in the JIT I can send a PR to rename OSX -> Apple.

[MichalStrehovsky]

As far as I can see the JIT would be fine with a generic "Apple" value, except for the compatibility checks. E.g. this one:

That compatibility check also uses TargetOS::IsMacOSX above which is currently broken #87794 without anything noticing - I don't know what this actually does.

If you think that we don't need this distinction in the JIT I can send a PR to rename OSX -> Apple.

If we're only discussing renaming this within the JIT, this is now fully a JIT issue, so I'm moving this to that area and leaving the call on the JIT team.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Initial support for targeting iOS-like platforms with NativeAOT introduced with: #81476 uses a workaround in JIT interface:

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Line 3066 in 8f19f4e

target.IsOSXLike ? CORINFO_OS.CORINFO_MACOS : CORINFO_OS.CORINFO_UNIX;

hardwiring the compilation as if the target platform is macOS which also brings along corresponding implications on the native side.

Author:	ivanpovazan
Assignees:	-
Labels:	area-CodeGen-coreclr, os-ios
Milestone:	8.0.0

[JulieLeeMSFT]

cc @dotnet/jit-contrib. @jakobbotsch please take a look.

[jakobbotsch]

If you think that we don't need this distinction in the JIT I can send a PR to rename OSX -> Apple.

Indeed I don't think we need the distinction. Feel free to submit a PR to rename the value. I'm going to move the issue to future since this is just a cosmetic change.