search

dotnet / corert

This repo contains CoreRT, an experimental .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying compiler toolchain.
http://dot.net
MIT License
2.91k stars 508 forks source link

Android (ARM64) support #8316

Open RalfKornmannEnvision opened 4 years ago

RalfKornmannEnvision commented 4 years ago

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 commented 4 years ago

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

RalfKornmannEnvision commented 4 years ago

Two issues solved:

One is work in progress

Unfortunately I found another one

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.