[NativeAOT] Low level API support for Objective-C scenarios

[AustinWise]

.NET 6 added some APIs to CoreCLR to support running the macOS version of Xamarin-macios. Reference:

• Approved API shape
• dotnet/design proposal

High level questions about how to approach implementing this

• Is it desired to support this API in NativeAOT?
• Can the work to support the ObjectiveCMarshal API be split over multiple PRs. If so, is there a recommended way to turn off the feature for release builds, but still have the CI system test the feature?

Outline of work

• ObjectiveCMarshal API :
  • [NativeAOT] Objective-C: SetMessageSendPendingException and SetMessageSendCallback #77956
  • [NativeAOT] Objective-C Marshal: object tracker support #78280
  • [NativeAOT] Objective-C exception propagation #80334
• Testing: some of the tests for this API rely on Remote Executor, which is not currently supported by NativeAOT RemoteExecutor: support single file and NativeAOT arcade#11460
• [NativeAOT] support calling UnmanagedCallersOnly functions before managed main() #77957
• Xamarin-macios side work that is outside the scope of this issue. For a complete list see Enable support for NativeAOT targeting iOS via opt-in feature #80905
  • Support for using the aforementioned NativeAOT hosting API.
  • Changes to packaging to include the new NativeAOT-specific build of the native components.
  • Change build system to account for NativeAOT when linking IL and enabling/disabling features like static registrar
  • Changes to the build system to integrate with the final application linking that NativeAOT does.
  • Support for retaining enough metadata and marshaling information to allow the runtime to work.

Unimplemented parts of the API

Since the Xamarin side does not use the lastMethod parameter of the UnhandledExceptionPropagationHandler delegate, implmenting that is tracked in a separate issue: #80985

[jkotas]

Is it desired to support this API in NativeAOT?

Yes, we are happy to merge contributions that fill in missing functionality in NativeAOT.

Xamarin-macios uses the CoreCLR hosting functions coreclr_initialize, coreclr_create_delegate, and coreclr_execute_assembly to execute some managed code before the application-defined main method starts running.

These CoreCLR hosting APIs do not make a lot of sense in NativeAOT world. The basic NativeAOT hosting primitive is UnmanagedCallersOnly method exported as C entrypoint. https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary is a sample that shows how to it.

[jkotas]

Can the work to support the ObjectiveCMarshal API be split over multiple PRs

Yes, that's fine. Smaller PRs are typically reviewed and merged faster that makes it easier to make progress.

[lambdageek]

/cc @ivanpovazan

[AustinWise]

Xamarin-macios uses the CoreCLR hosting functions coreclr_initialize, coreclr_create_delegate, and coreclr_execute_assembly to execute some managed code before the application-defined main method starts running.

These CoreCLR hosting APIs do not make a lot of sense in NativeAOT world. The basic NativeAOT hosting primitive is UnmanagedCallersOnly method exported as C entrypoint. https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary is a sample that shows how to it.

I agree that the full set of CoreCLR hosting APIs does not make sense for NativeAOT. The only feature that Xamarin-macios needs from a "hosting" API is the ability to call UnmanagedCallersOnly functions and before the application's main method. I have filed #77957 for this feature.

[AaronRobinsonMSFT]

@AustinWise Marking this as future since there is no rush and no expectation all of it will be done in .NET 8. If you are able to make it happen hooray, just don't want to put undue pressure on you.