Closed yowl closed 1 year ago
@yowl w.r.t. test failures, it looks like https://github.com/dotnet/runtime/pull/86855#discussion_r1209557982.
@yowl w.r.t. test failures, it looks like dotnet/runtime#86855 (comment).
Thanks I did read that at the time, sorry.
I'm still a bit stuck on how best to solve this. In InstanceMethodInvoker
I changed RawCalliHelper
to
private static class RawCalliHelper
{
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static T Call<T>(delegate*<IntPtr, T> pfn, IntPtr arg)
#if TARGET_WASM
{
object obj = System.Runtime.RuntimeImports.RhpRawCalli_OI((IntPtr)pfn, arg);
return Unsafe.As<object, T>(ref obj);
}
#else
=> pfn(arg);
#endif
}
But that generates this:
define ptr @"S_P_Reflection_Execution_Internal_Reflection_Execution_MethodInvokers_InstanceMethodInvoker_RawCalliHelper__Call<System___Canon>"(ptr %0, ptr %1, ptr %2, i32 %3) {
BB00:
%4 = alloca ptr, align 4
store ptr %1, ptr %4, align 4
%5 = alloca ptr, align 4
store ptr %2, ptr %5, align 4
%6 = alloca i32, align 4
store i32 %3, ptr %6, align 4
%7 = alloca ptr, align 4
store ptr null, ptr %7, align 4
%8 = alloca ptr, align 4
store ptr null, ptr %8, align 4
br label %BB01
BB01: ; preds = %BB00
store ptr null, ptr %0, align 4
br label %BB02
BB02: ; preds = %BB01
%9 = load ptr, ptr %5, align 4
store ptr %9, ptr %7, align 4
%10 = load i32, ptr %6, align 4
%11 = load ptr, ptr %7, align 4
%12 = getelementptr i8, ptr %0, i32 4
%13 = call ptr %11(ptr %12, i32 %10)
store ptr %13, ptr %0, align 4
%14 = load ptr, ptr %0, align 4
ret ptr %14
}
%13 = call ptr %11(ptr %12, i32 %10)
the second parameter is i32
but this is going to end being passed to, for example:
COOP_PINVOKE_HELPER(Object *, RhpNewFinalizableAlign8, (MethodTable* pEEType))
%10
comes from the arg %3
which is i32
but that looks wrong to me. I'll see why the signature RawCalliHelper.Call
is as it is.
I think this is the explanation for the current failure:
RuntimeError: null function or function signature mismatch
at S_P_Reflection_Execution_Internal_Reflection_Execution_MethodInvokers_InstanceMethodInvoker_RawCalliHelper__Call<System___Canon> (wasm://wasm/076a667a:wasm-function[6098]:0x562c75)
It looks odd that the code is performing an indirect call, it should call the runtime import. Is S.P.Reflection.Execution
compiled as a target-specific assembly, i. e. is the #if
effective?
It looks odd that the code is performing an indirect call, it should call the runtime import. Is
S.P.Reflection.Execution
compiled as a target-specific assembly, i. e. is the#if
effective?
Right, I think I just didn't compile something. Problem looks like a GC hole (if that's the right term) now. Trouble with these things are that it is difficult to be sure the problem is with the merge and wasn't just latent.
Note #2312 introduced a GC hole (but I don't think this branch is based on it).
It is suspicious that S_P_CoreLib_System_Runtime_RawCalliHelper__Call_7
is still in the call stack here. B282745
is also quite a stress test for the robustness of a conservative GC.
It is suspicious that
S_P_CoreLib_System_Runtime_RawCalliHelper__Call_7
is still in the call stack here
From https://github.com/dotnet/runtimelab/blob/f390a9ca067cd0e11137a8c6a28e250ab23a3d9a/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/DynamicInvokeInfo.cs#L234 or https://github.com/dotnet/runtimelab/blob/f390a9ca067cd0e11137a8c6a28e250ab23a3d9a/src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/DynamicInvokeInfo.cs#L259
That's ok though isn't it? Or you think there might be paths through these to unmanaged methods?
That's ok though isn't it?
Agree; it doesn't actually look relevant.
but I don't think this branch is based on it
Actually, I forgot that CI merges main before running, so #2312 is indeed in the commit list here. I have been actively looking at the issue and hope to have the fix up soon.
I forgot that CI merges main before running
Ok, great, I have to resolve some conflicts also.
Removed some tests for MD Arrays in DynamicGenerics
because they start failing from https://github.com/dotnet/runtime/pull/86877
Last commit is remoivng IsServerGC check: my understanding is Wasm won't get that as it is not multiprocessor. I also removed RawCalliHelper
by mistake in a merge, so I put that back (without the Wasm workaround of course).
cc @dotnet/nativeaot-llvm as removing from draft.
Thank you!
This PR moves us forward to 23 June 23
@SingleAccretion I'm getting this error running the tests, can you recall anything upstream that might have affected this, or would waiting for https://github.com/dotnet/runtimelab/pull/2312 make sense as it seems to be about signatures: