| Format | Assembly Format | Description |
|---|---|---|
| 29 <T> | calli callsitedescr |
Call method indicated on the stack with arguments described by callsitedescr. |
…, arg0, arg1 … argN, ftn → …, retVal (not always returned)
The calli instruction calls ftn (a pointer to a method entry point) with the arguments arg0 … argN. The types of these arguments are described by the signature callsitedescr. (See Partition I for a description of the CIL calling sequence.) The calli instruction can be immediately preceded by a tail. prefix to specify that the current method state should be released before transferring control. If the call would transfer control to a method of higher trust than the originating method the stack frame will not be released; instead, the execution will continue silently as if the tail. prefix had not been supplied.
[A callee of "higher trust" is defined as one whose permission grant-set is a strict superset of the grant-set of the caller.]
The ftn argument must be a method pointer to a method that can be legitimately called with the arguments described by callsitedescr (a metadata token for a stand-alone signature). Such a pointer can be created using the ldftn or ldvirtftn instructions, or could have been passed in from native code.
The standalone signature specifies the number and type of parameters being passed, as well as the calling convention (See Partition II) The calling convention is not checked dynamically, so code that uses a calli instruction will not work correctly if the destination does not actually use the specified calling convention.
The arguments are placed on the stack in left-to-right order. That is, the first argument is computed and placed on the stack, then the second argument, and so on. The argument-building code sequence for an instance or virtual method shall push that instance reference (the this pointer, which shall not be null) first. [Note: for calls to methods on value types, the this pointer is a managed pointer, not an instance reference. §I.8.6.1.5. end note]
The arguments are passed as though by implicit starg (§III.3.61) instructions, see Implicit argument coercion §III.1.6.
calli pops the this pointer, if any, and the arguments off the evaluation stack before calling the method. If the method has a return value, it is pushed on the stack upon method completion. On the callee side, the arg0 parameter/this pointer is accessed as argument 0, arg1 as argument 1, and so on.
System.SecurityException can be thrown if the system security does not grant the caller access to the called method. The security check can occur when the CIL is converted to native code rather than at runtime.
Correct CIL requires that the function pointer contains the address of a method whose signature is method-signature compatible-with that specified by callsitedescr and that the arguments correctly correspond to the types of the destination function's this pointer, if required, and parameters. For the purposes of signature matching, the HASTHIS and EXPLICITTHIS flags are ignored; all other items must be identical in the two signatures. Unlike Verified CIL, Correct CIL also allows a native int to be passed as a byref (&); in which case following the store the value will be tracked by garbage collection.
[Note: In correct CIL, the required type of an instance function's this pointer is not included in callsitedescr if HASTHIS is set and EXPLICITTHIS is not set; but to be correct, the type of the supplied this parameter must be appropriate for the called function. end note]
Verification checks that:
-
the tracked type of ftn is a method signature (e.g., ftn was generated by
ldftn,ldvirtfn, or loaded from a variable with the function type); -
if ftn's tracked method signature specifies an instance method then a value for this pointer is on the stack and its verification type is verifiable-assignable-to (§III.1.8.1.2.3) method signature's this pointer; and
-
the argument types are verifier-assignable-to (§III.1.8.1.2.3) the types of ftn's tracked method signature parameters.
If the call returns a value then verification also tracks that the type of the value returned as the intermediate type of ftn's tracked method signature's return type.
[Note: In the case of calling via a method pointer produced by ldvirtftn, which has a statically indeterminate this pointer type (and thus did not verify), the calli instruction does not verify. end note]
[Note: Verification is based on the tracked type of ftn and not callsitedescr as the former may carry the type of this in the case that the latter does not. However, verification requires correctness so the tracked type of ftn must be method-signature compatible-with sitedescr, the latter is not simply ignored. end note]