Android (ARM64) support

[RalfKornmannEnvision]

I am aware that Android is not on the supported systems list for CoreRT. Beside of this with Xamarin available the demand might not be very high anyway. 

But out of curiosity I hacked a little proof of concept together. It reaches the main function and can write some system information to the Console (stdout). Just a little bit more that the usual hello world app. Debugging seems to work fine, too. Only the general support for native Android applications in Visual Studio could need some love. But I am barking on the wrong tree here.

While I needed to add some ugly hacks I have the general felling that we are not that far away from getting it fully working. So far there are only 3 know issues left that need a proper fix. All in the runtime the compiler part works just fine. There might be more that pop up when these 3 are fixed.

While Android is still a Linux at the core (TARGET_UNIX) some places will need special code. Would the preprocessor define for this an additional TARGET_ANDROID or something else?

[jkotas]

TARGET_ANDROID sounds good. It is the define used by http://github.com/dotnet/runtime for Android.

[RalfKornmannEnvision]

Two issues solved:

• membarrier crashes Android before version Q
• Android uses a TLS emulation instead of the real deal

One is work in progress

• Calls between different object files trash X16&X17. This causes FEATURE_CACHED_INTERFACE_DISPATCH and thunks not working.

Unfortunately I found another one

• Stackwalking crashes when there is one or more of the special functions (like RhpThrowEx) in the call stack.

I think the last two problems are both related to the requirement that Android needs position independent code. This messes up pointers to functions. Therefore there might be some issues related to this

Should still be fixable but might introduce some more overhead compared to a build that don't need position independent code.

In any case I am surprised how many things are actually already seem to work.

Beside of the code itself there will be some work needed on the buildscripts. But I think this should be postponed until the move to runtimelab is done as the Android build need to include some code from the runtime to get the BCL working.

And finally we will need C# bindings to at least the native Android APIs to do something usefull. But this could be just a totally independent project

[jkotas]

Calls between different object files trash X16&X17.

Is there a way to tell the linker to use direct calls when the different object files are linked into a single binary? Maybe the symbols need to be defined as private or something to avoid involving dynamic loaded in cases like this?

[RalfKornmannEnvision]

Calls between different object files trash X16&X17.

Is there a way to tell the linker to use direct calls when the different object files are linked into a single binary? Maybe the symbols need to be defined as private or something to avoid involving dynamic loaded in cases like this?

Thanks for the tip. I was already looking into this direction but you pointed me in the right direction. Beside of global the symbols for the assembler functions need although be hidden. This way there is no entry in the GOT and the linker is forced to resolve the reference directly. 

The final stack walk issue seems to need something more but I haven't really started looking into it yet.

But beside of this the GC and simple try/catch is working. Still need to check the hardware based exceptions and threading. Unfortunately anything network related pulls in the crypto functions and I need to figure out how these need to build for Android. But as Xamarin implemented the BCL for Android already I am sure there is a solution that I just need to adopt. Globalization is although still inactive as I am running in Invariant mode. 

In any case I think this could become a usable replacement for Android apps that were done with the NDK so far.

[jkotas]

network related pulls in the crypto functions and I need to figure out how these need to build for Android. But as Xamarin implemented the BCL for Android already I am sure there is a solution that I just need to adopt. Globalization is although still inactive as I am running in Invariant mode.

Xamarin Android (based on https://github.com/mono/mono) had a solution for these issues. The solution was not ported yet to .NET Core. It is something that the team plans to work on for .NET 6. It will be closer to reimplementation than a port for various reasons.

[RalfKornmannEnvision]

Found the reason for the stack walk crash. The data type in the EXPORT_POINTER_TO_ADDRESS macro was a word instead of a quad.The assembler on the Switch seems to have ignored this and put the correct relocation information there while the android one has not copied the complete address there. Now the exception tests works including the hardware null ref exceptions. 

Until I find more issues we can assume that a fully working CoreRT version for Android can be build.