c# - 更改 callvirt 以在 IL 中调用

Question

在 IL 的一些实验中，我试图将程序集中的 callvirt 调用更改为 call 方法。基本上发生的事情是我有一个继承链，其中包含我正在调用的成员函数。

基本上调用与此类似:

((MyDerivedClass)myBaseObject).SomeCall();

或在 IL

castclass MyDerivedClass   // ** 1
call SomeCall()            // ** 2

基类定义SomeCall为抽象方法，派生类实现。派生类是密封的。

我知道 callvirt 基本上等同于检查对象是否为 null，如果它不是使用 vtable 调用方法，如果是，则抛出异常 .在我的例子中，我知道它永远不会是 null 并且我知道这是我想要调用的实现。我理解为什么在这种情况下您通常需要 callvirt。

也就是说，因为我知道该对象永远不会为 null，并且始终是派生类型的实例，所以我认为这不是问题:

• 当你认为数据和类型是分开的时，我实际上认为 (**1) 可以被删除(对象的数据将是相同的)和
• (**2) 可以是一个简单的调用，因为我们确切地知道要调用哪个成员。不需要 vtable 查找。

在我看来，编译器在某些情况下也可以推断出这是一件非常合理的事情。对于那些感兴趣的人，是的，callvirt 有速度损失，尽管它很小。

但是。 PEVerify 告诉我这是错误的。作为一个好 child ，我总是注意 PEVerify 告诉我的内容。那我在这里错过了什么？为什么更改此调用会导致不正确的程序集？

---

显然，创建一个最小测试用例并不是那么简单……到目前为止，我的运气并不好。

至于问题本身，我可以简单地在更大的程序中重现它:

[IL]: Error: [C:\tmp\emit\test.dll : NubiloSoft.Test::Value][offset 0x00000007] The 'this' parameter to the call must be the calling method's 'this' parameter.

值的IL代码:

L_0000: ldarg.0 
L_0001: ldfld class NubiloSoft.Test SomeField
L_0006: ldarg.1 
L_0007: call instance bool NubiloSoft.Test::Contains(int32)

字段的类型是NubiloSoft.Test。

至于Contains，在基类中是抽象的，在派生类中是重写的。正如您所期望的那样。当我删除“抽象基方法”+“覆盖”时，PEVerify 再次喜欢它。

为了重现我这样做的问题，到目前为止还没有在最小的测试用例中重现它:

public abstract class FooBase
{
    public abstract void MyMethod();
}

// sealed doesn't seem to do anything...
public class FooDerived : FooBase 
{
    public override void MyMethod()
    {
        Console.WriteLine("Hello world!");
    }
}

public class FooGenerator
{
    static void Main(string[] args)
    {
        Type t = CreateClass();

        object o = Activator.CreateInstance(t, new[] { new FooDerived() });
        var meth = t.GetMethod("Caller");
        meth.Invoke(o, new object[0]);

        Console.ReadLine();
    }

    public static Type CreateClass()
    {
        // Create assembly
        var assemblyName = new AssemblyName("testemit");
        var assemblyBuilder =
            AppDomain.CurrentDomain.DefineDynamicAssembly(assemblyName,
            AssemblyBuilderAccess.RunAndSave, @"c:\tmp");

        // Create module
        var moduleBuilder = assemblyBuilder.DefineDynamicModule("testemit", "test_emit.dll", false);

        // Create type : IFoo
        var typeBuilder = moduleBuilder.DefineType("TestClass", TypeAttributes.Public, typeof(object));

        // Apparently we need a field to trigger the issue???
        var field = typeBuilder.DefineField("MyObject", typeof(FooDerived), FieldAttributes.Public);

        ConstructorBuilder constructorBuilder = typeBuilder.DefineConstructor(
            MethodAttributes.Public | MethodAttributes.HideBySig |
            MethodAttributes.SpecialName | MethodAttributes.RTSpecialName,
            CallingConventions.HasThis, new Type[] { typeof(FooDerived) });

        // Generate the constructor IL. 
        ILGenerator gen = constructorBuilder.GetILGenerator();

        // The constructor calls the constructor of Object
        gen.Emit(OpCodes.Ldarg_0);
        gen.Emit(OpCodes.Call, typeof(object).GetConstructor(Type.EmptyTypes));

        // Store the field
        gen.Emit(OpCodes.Ldarg_0);
        gen.Emit(OpCodes.Ldarg_1);
        gen.Emit(OpCodes.Stfld, field);

        // Return
        gen.Emit(OpCodes.Ret);

        // Add the 'Second' method
        var mb = typeBuilder.DefineMethod("Caller",
            MethodAttributes.HideBySig | MethodAttributes.NewSlot | MethodAttributes.Virtual |
            MethodAttributes.Final | MethodAttributes.Public, CallingConventions.HasThis,
            typeof(void), Type.EmptyTypes);

        // Implement
        gen = mb.GetILGenerator();

        gen.Emit(OpCodes.Ldarg_0);
        gen.Emit(OpCodes.Ldfld, field);
        gen.Emit(OpCodes.Call, typeof(FooDerived).GetMethod("MyMethod"));
        gen.Emit(OpCodes.Ret);

        Type result = typeBuilder.CreateType();

        assemblyBuilder.Save("testemit.dll");

        return result;
    }
}

当你运行它并调用 peverify 时，它会告诉你代码没有错误...:-S

我不确定这里发生了什么......在我看来它非常相似。

Answer 1

我怀疑 this blog post是相关的。特别是:

Some consider this a violation of privacy through inheritence. Lots of code is written under the assumption that overriding a virtual method is sufficient to guarantee custom logic within gets called. Intuitively, this makes sense, and C# lulls you into this sense of security because it always emits calls to virtual methods as callvirts.

然后:

Late in Whidbey, some folks decided this is subtly strange enough that we at least don’t want partially trusted code to be doing it. That it’s even possible is often surprising to people. We resolved the mismatch between expectations and reality through the introduction of a new verification rule.

The rule restricts the manner in which callers can make non-virtual calls to virtual methods, specifically by only permitting it if the target method is being called on the caller’s ‘this’ pointer. This effectively allows an object to call up (or down, although that would be odd) its own type hierarchy.

换句话说，假设此更改是您正在谈论的内容(听起来像)，规则是为了防止 IL 违反对虚拟方法调用方式的正常预期。

您可能想尝试在 MyDerivedClass 中制作 SomeCall 方法 sealed... 那时它不再是虚拟的在 MyDerivedClass 类型的引用上调用 SomeCall 将 总是 调用相同的方法...对于 peverify 是否足够非虚拟是不过是另一回事:)