What is needed to add support for a new Native AOT platform?

[pixelomer]

I am trying to add support for a new Native AOT platform. I could find some documentation on how to optimize native builds on existing platforms, but none on how to add support for a new platform. Where should I look? What do I need to do?

My target platform is similar to an iPhone in that it has an ARM64 processor, does not support JIT and will not be able to run the dotnet tool directly. Furthermore, it does not support dynamic libraries, so the resulting binaries will need to be statically linked.

[dotnet-policy-service[bot]]

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

[huoyaoyuan]

/cc @filipnavara

Can you describe the operating system or similar system services on your platform? This will decide the works necessary or even feature availability.

I've heard successful runs of NativeAOT on barebone UEFI environment without OS, but its feature would be very limited.

[pixelomer]

The platform has its own kernel and its syscalls are completely different from Linux. It doesn't have a traditional filesystem. The platform does support networking and I/O but their implementation is not compliant with any standard. I was hoping that unsupported functionality could either be removed or simulated as needed.

The toolchain for the system seems to provide all of the tools required by dotnet. C and C++ are supported and static builds of some common libraries are provided. Pthreads are supported as well. The executable format of the platform is very similar to ELF.

[huoyaoyuan]

Basically, NativeAOT executable files are produced by RyuJIT->ObjWriter->platform linker. Since it's an usual ARM64 processor, there's likely no modification required for RyuJIT. You may need to update ObjWriter at https://github.com/dotnet/runtime/tree/main/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/ObjectWriter to provide object files for your platform.

Then you need to implement the syscalls required for the runtime. I'm aware of the ones at https://github.com/dotnet/runtime/tree/main/src/coreclr/nativeaot/Runtime . The bare minimum should include threading and others required by GC.

I/O and networking lives higher on the stack. On Unix-like systems a binary PAL layer is used to forward actual syscalls.

I'm not a NativeAOT expert and may be missing something.

[MichalStrehovsky]

If this is Nintendo Switch, a native AOT port already exists but you need to be a licensed developer to get access (details at https://fna-xna.github.io/docs/appendix/Appendix-B%3A-FNA-on-Consoles/).

If you want to see how such port historically looked like, have a look at PRs authored by https://github.com/dotnet/corert/pulls?page=1&q=is%3Apr+author%3ARalfKornmannEnvision and related issues https://github.com/dotnet/corert/issues?q=is%3Aissue+is%3Aopen+commenter%3ARalfKornmannEnvision in the corert repo.

This was work to port to game consoles but with private SDK specific changes excluded. The commits essentially entail a port to a Unix-like ARM64 OS (at that time there was no ARM64 Linux support in the native AOT runtime, so it's a bunch of work for "new CPU architecture bringup", not just OS bringup), and some tweaks to allow closed source bits to operate.

[pixelomer]

Thank you for sharing these links. Yes, this is about the Nintendo Switch. I was hoping to use C# for homebrew applications.

[jkotas]

cc @jbevain