[NativeAOT] How can I implement dynamic internal calls(or Qcall) in my custom NativeAOT runtime?

[TickThunder]

I'm trying to implement Mono's add_internal_call API and the invocation of internal calls. I'm confused about how NativeAOT achieves internal call invocation. My idea is to modify the ILC's ILEmitter, similar to TypeSystemThrowingILEmitter, to generate native method calls. However, emitting IL is a bit difficult for me. Does anyone have any good suggestions?

[AustinWise]

Have you forked this repository and modified the runtime to have a new internal calls or qcalls? Or are you trying to statically linking to a library that is not defined in dotnet/runtime? The second is more common and documented, so I'll answer it first.

Generating direct calls for P/Invokes

See this article. Rather than allowing the .NET Runtime to lazily load shared libraries (.DLLs) when using P/Invoke, you can have the native linker either dynamically or statically link the final executable against native libraries.

Defining a new internal call in a custom NativeAOT runtime

This is only something you should do if you are forking this repository (dotnet/runtime) in order to add a new .NET runtime feature. It is much easier to use the method defined in the previous section, if possible.

I'll use an existing internal call, RhRegisterGcCallout, to illustrate how an internal call is defined in used. On the native side, use one of the FCIMPL macros to define the function. The number at the end of the FCIMPL macro is the number of parameters the function takes:

FCIMPL2(FC_BOOL_RET, RhRegisterGcCallout, GcRestrictedCalloutKind eKind, void * pCallout)
{
    // ...
}
FCIMPLEND

In the C# side, you use the RuntimeImport attribute to define the function:

[MethodImplAttribute(MethodImplOptions.InternalCall)]
[RuntimeImport(RuntimeLibrary, "RhRegisterGcCallout")]
internal static extern bool RhRegisterGcCallout(GcRestrictedCalloutKind eKind, IntPtr pCalloutMethod);

(RuntimeLibrary is a single asterisk)

Note that while the RuntimeImportAttribute is not public, the compiler matches by name. So you can define your own copy of RuntimeImportAttribute in your own code. For an example of calling a RuntimeImport function from outside of System.Private.CoreLib, see this repository. The from-dotnet-runtime directory contains the RuntimeImportAttribute and other code copied from the NativeAOT runtime.

Important note: if you are doing nothing in your internal call the blocks for any amount of time, you should use a QCALL instead. This will ensure that the garbage collector can suspend threads in a timely manner. See RhWaitForPendingFinalizers for an example of something implemented as a QCALL.

[TickThunder]

Thank you for your reply.
'dynamic' I mean runtime dynamic. I want to execute C++ functions in C# by obtaining their function pointers through another function(like mono_add_internal_call).
and I also want to know how RuntimeImportMethodNode is used in ILC / RyuJIT. I have not been able to find the corresponding source code.

[AustinWise]

You can use the function pointer support in C# to call unmanged functions from C#. Function pointers can be passed across P/Invoke calls. This is not NativeAOT specific

For example, in C you can define a function that returns a function pointer:

#include <stdio.h>

void my_function(void)
{
    printf("in my_function\n");
}

typedef void (*func_ptr)(void);

extern "C" func_ptr get_my_function(void)
{
    return &my_function;
}

Then you can P/Invoke to get the function pointer and then call the function pointer:

using System.Runtime.InteropServices;

unsafe class Program
{
    static void Main()
    {
        delegate* unmanaged<void> my_function = get_my_function();
        Console.WriteLine("calling from C#");
        my_function();
    }

    [DllImport("my-lib")]
    static extern delegate* unmanaged<void> get_my_function();
}

[AustinWise]

Oh, are you saying you want to emulates mono_add_internal_call in the NativeAOT runtime? If that's the case, ignore this answer I gave.

[AustinWise]

I hacked together a proof of concept. It shows one way of generating code of InternalCall methods. It is based on how IL is generated for P/Invoke calls:

AustinWise@56db902

There are lot of missing pieces:

• There is only one hard-coded function, rather than supporting registering functions.
• It currently assumes the platform default calling convention for native functions, which may or may not be right.
• It does not implement caching when looking up the function
• It does no marshalling of parameter types
• The GC is always transitioned to preemptive mode when calling the native function

The last two are where this will start to get complicated. In the sample in the documention and other icalls used by the mono runtime, I find object references being passed as parameters and returned. So some sort of marshaling would be required to make that work.

That said, if all the methods you want to use mono_add_internal_call with only use blittable types in their method signatures, this approach might work.

[TickThunder]

Actually, this approach involves marshalling. When the generated IL calls JitCompileMethod, the JIT will then call back _convertPInvokeCalliToCall, which generates another function for marshalling. I'm curious if there's a way to prevent this function from being generated and instead directly call the C++ function in the IL generation phase.

[AustinWise]

Are you saying at compile time you already know which C++ function an internal call maps to? And rather than looking up the C++ function at runtime, you want the internal call replaced with a direct function call to the C++ function?

[TickThunder]

"Are you saying at compile time you already know which C++ function an internal call maps to?"
Yes, but your implementation works too.

"And rather than looking up the C++ function at runtime, you want the internal call replaced with a direct function call to the C++ function?"
Emm, NO! I want to invoke C++ function without marshalling, and passing managed object as object* .
Like this

    // Allocate handle.
    [RuntimeImport(Redhawk.BaseName, "RhpHandleAlloc")]
    [MethodImpl(MethodImplOptions.InternalCall)]
    internal static extern IntPtr RhpHandleAlloc(object value, GCHandleType type);

    COOP_PINVOKE_HELPER(OBJECTHANDLE, RhpHandleAlloc, (Object *pObject, int type))
    {
        return GCHandleUtilities::GetGCHandleManager()->GetGlobalHandleStore()->CreateHandleOfType(pObject, (HandleType)type);
    }

Thanks a lot! 🙏

[AustinWise]

Oh, I see what you mean. If I try to pass an object across this, I hit the NotSupportedMarshaller.

Since it appears the RuntimeImport method is a little special in terms of how it is treated by marshaling (i.e. no marshaling whatsoever), I can think of different approaches:

Rewrite IL before running ILC

It might be easier to implement this as a step between running CSC and ILC. Basically you would rewrite an internal call like this:

namespace MyNameSpace;

class MyImports
{
    [MethodImpl(MethodImplOptions.InternalCall)]
    public static extern void MyTestMethod(MyTestObject obj);
}

into something like this:

namespace MyNameSpace;

class MyImports
{
    [MethodImpl(MethodImplOptions.InternalCall)]
    [RuntimeImport("*", "MonoStyleInternalCallStub_MyNameSpace_MyImports_MyTestMethod")]
    public static extern void MyTestMethod(MyTestObject obj);
}

You would then also generate a C file containing stubs:

extern void* LookupMonoInternalCall(const char* name);

typedef void (*MonoStyleInternalCallStub_MyNameSpace_MyImports_MyTestMethod_Fnptr)(void*);

extern "C" void MonoStyleInternalCallStub_MyNameSpace_MyImports_MyTestMethod(void* obj)
{
    static MonoStyleInternalCallStub_MyNameSpace_MyImports_MyTestMethod_Fnptr cache = NULL;
    if (cache == NULL)
    {
        cache = (MonoStyleInternalCallStub_MyNameSpace_MyImports_MyTestMethod_Fnptr)LookupMonoInternalCall("MyNameSpace.MyImports::MyTestMethod");
    }
    cache(obj);
}

After running ILC, you would also compile the C file containing the stubs and link the resulting object file into the final executable.

Implement stubs in ILC

You could probably also implement this rewrite in ILC. Basically you would change the CreateMethodEntrypointNode methods to detect your internal call and return a RuntimeImportMethodNode node with the managed name. You can change ILC to also emit the C file with the stubs.

I think actually generating the stubs in ILC might be challenging. You would have to either figure out how to emit IL that does not run afoul of the marshaling. Or you would have to emit platform specific code (see AssemblyStubNode).

[TickThunder]

I finally chose to use Mono.Cecil to modify IL between CSC and ILC, which is basically consistent with what you suggested. Thank you very much for your help!