我在 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
来自哪里)。
最佳答案
让我们尝试基于 the specification 手动构建字段签名.首先,字段签名在 §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
我们要引用
TypeSpec
0x1b000001,编码为 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 中显示的完全相同的签名。
关于.net - 不同类型在 CIL 中具有相同的签名,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27806905/