7

我在 CIL 中定义了一个字段,如下所示:

.field public int32 modopt(void*) fld

我把它编译成一个程序集。现在我将其更改为:

.field public int32 modopt(int16) fld

现在,ILDASM 怎么可能报告(当显示为十六进制时)这两个字段?

Field #1 (04000001)
-------------------------------------------------------
    Field Name: fld (04000001)
    Flags     : [Public]  (00000006)
    CallCnvntn: [FIELD]
    Field type:  CMOD_OPT 1b000001 I4
    Signature : 06 20 06 08 

此代码查找完全相同的两个字段(实际上我创建了第二个字段以匹配报告的签名)。签名显然与第二个字段匹配,但第一个字段的签名应该是这样的:06 20 0f 01 08!我在这里想念什么?

编辑:

C# 不能发出这种类型的字段,引发关于自定义类型修饰符不支持的指针和数组类型的异常,因此这显然解决了签名不匹配的问题。但是为什么 ILDASM 允许创建无法反编译的无效签名的问题仍然存在。

编辑#2:

似乎 ILASM 实际上正在创建正确的 IL,我上次错过的十六进制转储有所不同:

//the first assembly
TypeSpec #1 (1b000001)
-------------------------------------------------------
    TypeSpec : Ptr Void
    Signature: 0f 01 

//the second assembly
TypeSpec #1 (1b000001)
-------------------------------------------------------
    TypeSpec : I2
    Signature: 06 

所以 ILDASM 十六进制转储中只有一个错误报告错误的成员签名(尽管我想知道06错误签名的来源)。

4

1 回答 1

1

让我们尝试根据规范手动构建字段签名。首先,字段签名在 §II.23.2.4 中定义。对于我们使用一个自定义修饰符的情况,它将是:

FIELD CustomMod Type

由于FIELD定义为 0x06,我们有:

06 CustomMod Type

我们的自定义修饰符是modopt,所以我们得到(基于 §II.23.2.7):

06 CMOD_OPT TypeDefOrRefOrSpecEncoded Type

CMOD_OPT为 0x20(§II.23.1.16):

06 20 TypeDefOrRefOrSpecEncoded Type

我们要引用TypeSpec0x1b000001,它被编码为 0b110(10 表示TypeSpec,1 表示 0x000001,§II.23.2.8)。然后将其“压缩”为单字节 0x06(§II.23.2):

06 20 06 Type

最后,类型为int32,即ELEMENT_TYPE_I4= 0x08(§II.23.2.12 和 §II.23.1.16):

06 20 06 08

所以我们得到的签名与 ILDasm 中显示的签名完全相同。

于 2015-01-07T23:38:37.237 回答