Get MethodInfo from managed function pointer?

[acaly]

C# 9.0 starts to support function pointers of managed methods in unsafe context. Although it's designed to be performance-orientated, I think it would still be nice to have an API to find the MethodInfo from the pointer in some cases, for example, to allow the program to provide debug info or to confirm that the signature of the function pointer is really correct.

I am not exactly sure whether this is easy or even possible in .NET Core, but I think the StackTrace class should be providing similar functionality internally. So is it possible to expose such functions in the core library?

[PathogenDavid]

If you don't strictly need a MethodInfo, but rather just information about the method the function pointer refers to, you can use ClrMD for this.

For example:

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
using Microsoft.Diagnostics.Runtime;
using System.Linq;

public static unsafe class Program
{
    public static void Main(string[] args)
    {
        IntPtr user32 = NativeLibrary.Load("User32.dll");

        delegate*<void> managed1 = &TestMethod;
        delegate*<void> managed2 = &AnotherMethod;
        delegate*<void> managed3 = &MessageBoxW;
        delegate* unmanaged<void> unmanaged1 = &UnmanagedMethod;
        delegate* unmanaged<void> unmanaged2 = (delegate* unmanaged<void>)NativeLibrary.GetExport(user32, "MessageBoxW");

        // Note that this means any methods JITted after we create the snapshot won't be available
        // You can use AttachToProcess on yourself, but it's not supported.
        // https://github.com/microsoft/clrmd/blob/master/doc/FAQ.md#can-i-use-this-api-to-inspect-my-own-process
        using DataTarget target = DataTarget.CreateSnapshotAndAttach(Process.GetCurrentProcess().Id);
        ClrRuntime runtime = target.ClrVersions.First().CreateRuntime();

        void Test(string testName, void* functionPointer)
        {
            ClrMethod? method = runtime.GetMethodByInstructionPointer((ulong)functionPointer);

            if (method is null)
            {
                Console.WriteLine($"{testName}: Not found");
                return;
            }

            Console.WriteLine($"{testName}: {method.Signature}");
        }

        Test("managed1", managed1);
        Test("managed2", managed2);
        Test("managed3", managed3);
        Test("unmanaged1", unmanaged1);
        Test("unmanaged2", unmanaged2); // This is expected to not be found because it's a native method
    }

    public static void TestMethod()
    { }

    public static void AnotherMethod()
    {}

    [UnmanagedCallersOnly]
    public static void UnmanagedMethod()
    { }

    [DllImport("User32.dll")]
    public static extern void MessageBoxW(); // Obviously this won't be callable, it's just here so it resolves
}

Here's the output you can expect from this:

managed1: Program.TestMethod()
managed2: Program.AnotherMethod()
managed3: Program.MessageBoxW()
unmanaged1: Program.UnmanagedMethod()
unmanaged2: Not found

(unmanaged2 isn't found because it's a function pointer to native code.)

---

If you need a MethodInfo, it seems to be possible using the information provided by ClrMD, but from what I can find there's no public API to get a MethodInfo back from an raw method handle. There is however an internal API for it: RuntimeType.GetMethodBase.

I made a nasty little proof of concept to call it using reflection just to prove it works:

using System;
using System.Reflection;

internal static class MethodBaseHelper
{
    private static Type? RuntimeMethodHandleInternal;
    private static ConstructorInfo? RuntimeMethodHandleInternal_Constructor;
    private static Type? RuntimeType;
    private static MethodInfo? RuntimeType_GetMethodBase;

    public static MethodBase? GetMethodBaseFromHandle(IntPtr handle)
    {
        RuntimeMethodHandleInternal ??= typeof(RuntimeMethodHandle).Assembly.GetType("System.RuntimeMethodHandleInternal", throwOnError: true)!;
        RuntimeMethodHandleInternal_Constructor ??= RuntimeMethodHandleInternal.GetConstructor
        (
            BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.DoNotWrapExceptions,
            binder: null,
            new[] { typeof(IntPtr) },
            modifiers: null
        ) ?? throw new InvalidOperationException("RuntimeMethodHandleInternal constructor is missing!");

        RuntimeType ??= typeof(Type).Assembly.GetType("System.RuntimeType", throwOnError: true)!;
        RuntimeType_GetMethodBase ??= RuntimeType.GetMethod
        (
            "GetMethodBase",
            BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.DoNotWrapExceptions,
            binder: null,
            new[] { RuntimeType, RuntimeMethodHandleInternal },
            modifiers: null
        ) ?? throw new InvalidOperationException("RuntimeType.GetMethodBase is missing!");

        // Wrap the handle
        object runtimeHandle = RuntimeMethodHandleInternal_Constructor.Invoke(new[] { (object)handle });
        return (MethodBase?)RuntimeType_GetMethodBase.Invoke(null, new[] { null, runtimeHandle });
    }
}

If you add the following after the Console.WriteLine in the Test local function:

            MethodBase? methodBase = MethodBaseHelper.GetMethodBaseFromHandle((IntPtr)method.MethodDesc);
            Console.WriteLine($"    MethodBase: {methodBase?.Name ?? "Not Found"}");

You get the following output:

managed1: Program.TestMethod()
    MethodBase: TestMethod
managed2: Program.AnotherMethod()
    MethodBase: AnotherMethod
managed3: Program.MessageBoxW()
    MethodBase: MessageBoxW
unmanaged1: Program.UnmanagedMethod()
    MethodBase: UnmanagedMethod
unmanaged2: Not found

If you only want this for debugging then maybe this is good enough. If not, you'd probably have to open an API request in dotnet/runtime. Not sure how they'll feel about an API to get a MethodInfo from a function pointer directly, but I feel like safe, public wrapper to get a MethodBase back from a raw method handle IntPtr isn't all that unreasonable. (I'm kinda surprised it doesn't already exist, actually.)

If you want to avoid using ClrMD, you could probably loop over all methods using reflection and compare using RuntimeMethodHandle.GetFunctionPointer, but that'd be super slow (unless you narrowed things down to just a specific type or assembly) and you'd be running into dangerous territory with tiered JITting (and other undescribed issues): dotnet/roslyn#48919

[acaly]

I don't think the runtime gives any sort of guarantee if you try to construct a delegate with an incompatible signature type

That's probably a good reason to have this API. As I said, one usage of this API is to validate the signature. If we don't know about the signature, then we cannot construct the delegate. Also it's not always easy to have a delegate with the same signature. Action and Func cannot be used with byrefs. I suggest we reopen #36363.

[GrabYourPitchforks]

Also it's not always easy to have a delegate with the same signature.

Not sure what you mean by this. If you have a delegate* managed<..., TRet>, it should always be possible to construct an equivalent delegate TRet MyDelegate(...). I can't think offhand of any instances where this wouldn't be possible. The exception would be if you're literally passing the function pointer around as a void* or an IntPtr or equivalent, but it'd be somewhat useless to do that since you can't invoke it without knowing the exact signature.

[acaly]

it'd be somewhat useless to do that since you can't invoke it without knowing the exact signature

That is true, unless you are writing something more generic (literally). Without the support of byref types as generic argument, and something like a variadic template in C++, one will find it difficult to write a library that helps user of the library to handle function pointers. I hope the first can be solved by the ref struct constraint proposal, and then the second can be somehow solved by defining a lot of generic types/methods with different number of generic parameters like Action and Func.

Please consider my following situation. I am working on an ECS library for games. Briefly, the function pointers, created by plugins, which do know about the signature, go through the library, which has no information of the signature and generally can only store them as IntPtr. These function pointers can be consumed by another plugin, who again, knows about the signature. I cannot use Delegate for some reasons, so there would be no Delegate types to pass around. Instead, the consumer defines a helper struct (with significant help of a source generator) to store the info and invoke the method. You can think of this as a re-implementation of the C# delegate. The runtime needs IntPtr to implement Delegates, so I would also have to use IntPtr.

I can let the producer to provide MethodInfo together with the function pointer in Debug builds for validation, or I can let the library to obtain the information from a Action delegate as described above.

[GrabYourPitchforks]

Why not follow Jan's suggestion in the original issue #36363? If you want to allow reflection, use a reflection type (MethodInfo) instead of raw pointers. Any interested party can always retrieve the function pointer from the reflection object (via MethodInfo.MethodHandle.GetFunctionPointer()). The consumer of the reflection object is now given a choice as to whether they want to use normal reflection APIs (MethodInfo,Invoke) or a fnptr-based system. Under this system there's no need for anybody to construct a delegate unless they want to.

Re: the source generator example, a source generator should have knowledge of the exact type of the fnptr, since it sits alongside the code that created that fnptr in the first place. Instead of passing around just the IntPtr, you could instead pass around a custom object that represents the (IntPtr, typeof(delegate* managed<...>)) tuple. Or use the existing System.Reflection.Pointer type for this, which is really just a glorified (void*, Type) tuple. We'd need to add a Pointer.Type property getter (which we should probably do anyway), and we'd need to address #11354 (which we're already considering). But the two of those combined should be able to convey the appropriate information without the need for MethodInfo if that route is viable.

[acaly]

Thanks for the suggestion. That's very similar to what I am thinking right now. I am really looking forward to the fix of #11354 (and probably dotnet/roslyn#48765) so that I can use this method to simplify it by replacing MethodInfo with a typeof(delegate*<...>).

The justification of having such an API was really that, as @PathogenDavid mentioned, there is already a function in netcore that does exactly the same work, so making it publicly available to C# isn't that difficult, at least technically. It can be really useful with function pointer, to make the code more robust and to print more useful debug info. Note that without this API, even we can have the typeof(delegate*<...>), we still need a delegate type to convert the pointer to MethodInfo. One may be able to construct such a delegate type as a (reusable) dynamic type if it is really necessary, but still it adds much complication to the user.

Do you think I should open another discussion or issue to discuss this? Or you think the team would choose not to implement this API? This discussion is becoming too long to read.