如何使用CPU本身来判断x86-64指令操作码的长度？

我知道有些库可以"解析"二进制机器代码/操作码来告诉x86-64 CPU指令的长度.

但我想知道,因为CPU有内部电路来确定这一点,有没有办法使用处理器本身来告诉二进制代码的指令大小？(甚至可能是黑客？)

EFLAGS/RFLAGS中的陷阱标志(TF)使CPU单步执行,即在运行一条指令后执行异常.

因此,如果编写调试器,则可以使用CPU的单步执行功能来查找代码块中的指令边界.但只有运行它,如果它出错(例如来自未映射地址的加载),你将获得该异常而不是TF单步异常.

(大多数操作系统都有附加和单步执行其他进程的工具,例如Linux ptrace,因此您可以创建一个无特权的沙盒进程,您可以在其中单步执行一些未知的机器代码字节...)

或者@Rbmn指出,您可以使用操作系统辅助的调试工具来单步执行.

@Harold和@MargaretBloom还指出你可以在页面的末尾放置字节(后跟一个未映射的页面)并运行它们.查看是否出现#UD,页面错误或#GP异常.

#UD:解码器看到一个完整但无效的指令.

未映射页面上的页面错误:解码器在确定它是非法指令之前命中未映射的页面.

#GP:由于其他原因,指令有特权或故障.

要排除解码+作为完整指令运行然后在未映射的页面上出现故障,请在未映射页面之前仅启动1个字节,并继续添加更多字节,直到您停止获取页面错误.

由Christopher Domas 打破x86 ISA进一步详细介绍了这种技术,包括使用它来查找未记录的非法指令,例如9a13065b8000d77字节非法指令; 这就是它停止页面错误的时候.(objdump -d只是说0x9a (bad)并解码其余的字节,但显然真正的英特尔硬件不满意它是坏的,直到它获取6个字节).

硬件性能计数器instructions_retired.any也会暴露指令计数,但是在不知道任何有关指令结束的信息的情况下,您不知道将rdpmc指令放在何处.使用0x90NOP 填充并查看执行了多少指令可能不会真正起作用,因为您必须知道在哪里切割并开始填充.

我想知道,为什么英特尔和AMD不会为此引入指令

对于调试,通常你想要完全反汇编指令,而不仅仅是找到insn边界.所以你需要一个完整的软件库.

将微编码反汇编程序放在一些新的操作码后面是没有意义的.

此外,硬件解码器只连接起来作为代码获取路径中前端的一部分,而不是为它们提供任意数据.他们已经忙于在大多数周期中解码指令,并且没有连线处理数据.添加解码x86机器码字节的指令几乎肯定会通过在ALU执行单元中复制该硬件来完成,而不是通过查询解码的uop缓存或L1i(在L1i中标记指令边界的设计中)或通过发送数据来完成实际的前端预解码器并捕获结果,而不是将其排队等待前端的其余部分.

我能想到的唯一真正的高性能用例是仿真,或支持英特尔软件开发仿真器(SDE)等新指令.但是如果你想在旧的CPU上运行新的指令,那么重点是旧的CPU 不知道那些新的指令.

与CPU进行浮点数学或图像处理所花费的时间相比,反汇编机器代码所花费的CPU时间非常少.有一个原因,我们vpsadbw在指令集中有像SIMD FMA和AVX2这样的东西,以加速CPU花费大量时间做的那些特殊用途的东西,但不是我们可以用软件轻松做的事情.

请记住,指令集的要点是可以创建高性能代码,而不是获取所有元数据并专门解码自身.

在特殊用途复杂性的上端,在Nehalem中引入了SSE4.2字符串指令.他们可以做一些很酷的东西,但很难使用. https://www.strchr.com/strcmp_and_strlen_using_sse_4.2(也包括的strstr,这是一个真正的用例,其中pcmpistri can be faster than SSE2 or AVX2, unlike for strlen / strcmp where plain oldPCMPEQB /pminub`工作非常好,如果有效地使用(见glibc的手书ASM).)无论如何,这些新指令甚至在Skylake中仍然是多用途的,并没有被广泛使用.我认为编译器很难用它们进行自动向量化,并且大多数字符串处理都是在语言中完成的,在这些语言中,以低开销紧密集成一些内在函数并不容易.

安装蹦床(用于热修补二进制函数.)

即使这需要解码指令,而不仅仅是找到它们的长度.

如果函数的前几个指令字节使用RIP相对寻址模式(或者a jcc rel8/rel32或甚至是jmp或者call),则将其移动到其他地方会破坏代码. (感谢@Rbmn指出这个角落的情况.)