Leave opcode question

[m-carrasco]

Hi,

I have been trying to understand how leave opcode changes the state of the stack according to the standard and how Cecil specifies it as well.

ECMA CIL defines it as follows:

So, in its semantics, it states that it empties the stack: ..., -> <empty>

Then, at the end of the specification, it defines it again but in the following way:

In this case, it states that they do not consume anything from the stack.

This "mismatch" is causing me not to fully understand if leave is actually consuming or not the elements in the stack. Must the stack be empty before leave is executed? In an empty catch handler, the compiler is adding a pop to remove the caught exception reference before leave is executed.

    public static void M() {
        try{
            Console.WriteLine("dummy method");
        } catch (Exception ex){
        }
    }

    .method public hidebysig static 
        void M () cil managed 
    {
        // Method begins at RVA 0x2050
        // Code size 16 (0x10)
        .maxstack 1

        .try
        {
            IL_0000: ldstr "dummy method"
            IL_0005: call void [System.Console]System.Console::WriteLine(string)
            IL_000a: leave.s IL_000f
        } // end .try
        catch [System.Private.CoreLib]System.Exception
        {
            IL_000c: pop
            IL_000d: leave.s IL_000f
        } // end handler

        IL_000f: ret
    } // end of method C::M

Would be legal bytecode not having the IL_000c: pop? Out of curiosity, I checked and Cecil defines leave as "PopAll".

I understand this is not a problem/issue with Cecil but I do have hope that this "problem" might have also been raised while developing it.

Thanks!
Manuel.

[ltrzesniewski]

ECMA-335 states the following:

The leave instruction empties the evaluation stack and ensures that the appropriate surrounding finally blocks are executed.

So this is the normative specification. I suppose the compiler just tries to emit "cleaner" IL by keeping the pop instruction (I'm also pretty sur that removing the pop instruction would require additional code in the compiler, for little benefit).

As for the OPDEF macros (which are informative BTW) Pop0 is defined as "no inputs", which is also true: the leave instruction does not really consume any input. I agree it's confusing though.

@jbevain would need to comment on where PopAll comes from, but I suppose it makes things easier to handle down the road. Note that there's no such item in System.Reflection.Emit.StackBehaviour.

Just to make sure, I compiled the following:

.method public hidebysig static 
	int32 Main () cil managed 
{
	.maxstack 1
	.entrypoint

	.try
	{
		IL_0000: newobj    instance void [System.Runtime]System.InvalidOperationException::.ctor()
		IL_0005: throw
	} // end .try
	catch [System.Runtime]System.Exception
	{
		IL_0006: leave.s   IL_0008
	} // end handler

	IL_0008: ldc.i4.s  42
	IL_000A: ret
} // end of method Program::Main

And it works fine (outputs an error code of 42). I also ran PEVerify on the net48 version, which did not find any issues.

[m-carrasco]

Thanks for your answer! Your example is super useful to me. My main concern was to understand whether your example is legal bytecode. In addition, I wasn't aware that the OPDEF macros were just informative, so thanks for that as well.

[jbevain]

@ltrzesniewski I honestly don't remember. Cecil 0.6 also has leave and leave.s set to PopAll.

[jbevain]

I assume from back then it makes it easier to compute what's going on with the stack by just working on the stack behavior of the OpCode instead of special casing instructions.

Found this with some Googling:

2005-06-21  Jb Evain  <[email protected]>

	* Mono.Cecil.Implem/ReflectionReader.cs: Correct a bug that prevents
		assemblies to be readed if they have an entrypoint. Suggestion by
		Mario Sopena
	* Mono.Cecil.Implem/CodeReader.cs: Use sbyte not to lose negatives
		offsets. Suggestion by Vladislav Spivak
	* CodeGen/cecil.xml,
	  Mono.Cecil.Cil/OpCodes.cs,
	  Mono.Cecil.Cil/StackBehaviour.cs: Add an PopAll enumeration value
		for StackBehaviour, and set the StackBehaviourPop property for
		leave and leave.s opcodes to it. Suggested by Vladislav Spavin

[ltrzesniewski]

Thanks for the info.

BTW, about the OPDEF macros: they're not normative, but they're used in the actual CLR implementation. This exposes some differences from the spec, such as the no. opcode not being implemented (listed as CEE_UNUSED69 instead).

[m-carrasco]

I assume from back then it makes it easier to compute what's going on with the stack by just working on the stack behavior of the OpCode instead of special casing instructions.

Absolutely, now I see its reason. Thanks @jbevain and @ltrzesniewski for all your feedback 👍