In NativeAOT, unmanaged calli that cannot be inlined (due to requiring marshaling, incompatible callsite for P/Invoke inlining, etc) use convertPInvokeCalliToCall to transform the calli into a call to a method. In CoreCLR, we instead use getCookieForPInvokeCalliSig to construct a VASigCookie and send the call through our GenericPInvokeCalliHelper, which generates an IL stub per-signature at invocation time.
With the work we've done to implement support for P/Invokes backed by transient IL, we can now create a DynamicMethodDesc backed by transient IL for unmanaged calli. Additionally, with the recently added support in ReadyToRun for emitting synthetic MethodDescs for runtime-async, we could also add support for generating ReadyToRun code for the non-inlined calli (very similar scenarios as where we generate non-marshaling P/Invoke stubs in crossgen2 today).
This would further allow us to more easily enable non-inlined unmanaged calli for WASM scenarios (ie no GenericPInvokeCalliHelper, just a direct call to a stub with an inlined unmanaged calli that crossgen2 or the interpreter can handle).
By moving the non-vararg scenarios for VASigCookie away from it, we would also be able to move all of the VASigCookie logic to be Windows-only (or more specifically, platforms with supported managed varargs-only), further reducing the amount of code that we must carry around on non-Windows (small size-on-disk reduction).
In NativeAOT, unmanaged calli that cannot be inlined (due to requiring marshaling, incompatible callsite for P/Invoke inlining, etc) use
convertPInvokeCalliToCallto transform the calli into a call to a method. In CoreCLR, we instead usegetCookieForPInvokeCalliSigto construct aVASigCookieand send the call through ourGenericPInvokeCalliHelper, which generates an IL stub per-signature at invocation time.With the work we've done to implement support for P/Invokes backed by transient IL, we can now create a
DynamicMethodDescbacked by transient IL for unmanaged calli. Additionally, with the recently added support in ReadyToRun for emitting synthetic MethodDescs for runtime-async, we could also add support for generating ReadyToRun code for the non-inlined calli (very similar scenarios as where we generate non-marshaling P/Invoke stubs in crossgen2 today).This would further allow us to more easily enable non-inlined unmanaged calli for WASM scenarios (ie no
GenericPInvokeCalliHelper, just a direct call to a stub with an inlined unmanagedcallithat crossgen2 or the interpreter can handle).By moving the non-vararg scenarios for VASigCookie away from it, we would also be able to move all of the VASigCookie logic to be Windows-only (or more specifically, platforms with supported managed varargs-only), further reducing the amount of code that we must carry around on non-Windows (small size-on-disk reduction).