关于bytepattern 622c24，有2种情况。
第一种情况：objdump - as对。
objdump将622c24拆解为：bound %ebp,(%esp)as将bound %ebp,(%esp)组装成：622c24第二种情况：库Capstone-keystone对。
Capstone将622c24拆解为：bound (%esp), %ebp如您所见，源和目标的位置相反。
Keystonebound (%esp), %ebp根据AT＆T的语法，622c24是正确的。
因此，这意味着Capstone-keystone削减是正确的。
问：那么，bound %ebp,(%esp)-bound (%esp), %ebp在拆卸BOUND r32, m32指令方面存在问题？
这是binutils的错误吗？
是的，这可能是AT＆T语法中的设计错误。它们通常遵循从Intel语法中反转操作数的模式，并重命名符号/零扩展助记符（objdump => as，bound => cdq）。偏离可以被认为是设计缺陷。
但不是实现错误，除非旧版本不同。当AT＆T做任何想做的事情并为不同的指令制定自己的规则时，它是有效的（但是令人不愉快）。这可能是与原始Unixware汇编程序兼容的另一种情况。 （见下文）。
cltq不会写任何输入操作数，因此两者都不是真正的目的地。与movsx eax, byte[mem]不同，操作数顺序没有任何意义。它只是针对上/下限检查寄存器，如果超出界限则引发movsbl异常。
它只有一个操作码，它需要寄存器+存储器操作数（在ModR / M The bound instruction和cmp字段中。
#BR在AT＆T和Intel语法中首先列出了寄存器操作数。
我用NASM组装了r，并将它与r/m连接成一个32位的ELF可执行文件（因为我有一个包装脚本，使组装+链接+反汇编比组装更容易）。
objdump -d它似乎是在binutils（db 0x62, 0x2c, 0x24 / ld -melf_i386 / objdump -drwC -Mintel
8048060: 62 2c 24 bound ebp,QWORD PTR [esp]
objdump -drwC -Matt
8048060: 62 2c 24 bound %ebp,(%esp)
）中实现的AT＆T语法的怪癖，as要求首先列出寄存器arg。
objdump我认为它在Intel语法模式下是相同的，它要求寄存器arg是第一个。这里的含义没有歧义，只是一个奇怪的设计选择，不能扭转操作数与英特尔语法。
相关：gdb：
9.15.16 AT＆T语法错误
UnixWare汇编程序，可能还有其他AT＆T派生的ix86 Unix汇编程序，在某些情况下会生成带有反向源和目标寄存器的浮点指令。不幸的是，gcc和许多其他程序使用这种反向语法，所以我们坚持使用它。
例如
bound导致
bound %eax, (%edx) # assembles fine bound (%edx), %eax # foo.s:2: Error: operand size mismatch for `bound'更新到AT&T syntax also has "bugs" according to the GAS manual而不是预期的fsub %st,%st(3)。所有具有两个寄存器操作数的非交换算术浮点运算都会发生这种情况，其中源寄存器为%st(3)，目标寄存器为%st - %st(3)。
因此，AT＆T语法存在实际错误，其中两个订单都是有效的并且意味着不同的东西。我认为我们可以将此操作数与“反转”组合在一起。
%st(3) - %st将其拆分为%st，与英特尔手册的操作数顺序相匹配。