这是汇编程序错误吗？绑定指令
Is this assembler bug? bound instruction
关于字节模式622c24，有2种情况。
第一种情况：objdump - as 对。
objdump 反汇编 622c24 为：bound %ebp,(%esp)- linux
as 将 bound %ebp,(%esp) 汇编为：622c24
第二种情况：库 Capstone- keystone 对。
Capstone 反汇编 622c24 为：bound (%esp), %ebp
Keystone 将 bound (%esp), %ebp 汇编为：622c24
正如您在上面看到的，源和目标的位置颠倒了。
- objdump :
bound %ebp,(%esp)
- 顶点：
bound (%esp), %ebp
根据 AT&T 语法，BOUND r32, m32 是正确的。
因此，这意味着 Capstone-keystone pare 是正确的。
问。那么，objdump-as反汇编bound指令有问题吗？
是不是binutils的bug？
是的，这可能是 AT&T 语法中的一个设计错误。它们通常遵循从 Intel 语法反转操作数的模式，并重命名 sign/zero-extension 助记符（cdq => cltq、movsx eax, byte[mem] => movsbl） .与此的偏差可视为设计错误。
但不是实现错误，除非旧版本不同。当 AT&T 随心所欲并为不同的指令制定自己的规则时，这是有效的（但令人不快）。这可能是与原始 Unixware assembler 兼容的另一种情况。 （见下文）。
The bound instruction 不写入任何一个输入操作数 ，因此两者都不是真正的目的地。与 cmp 不同的是，操作数顺序没有任何意义。它只是根据 upper/lower 边界检查寄存器，如果超出边界则引发 #BR 异常。
它只有一个操作码，它需要寄存器 + 内存操作数（在 ModR/M r 和 r/m 字段中。
objdump -d 在 AT&T 和 Intel 语法中首先列出寄存器操作数。
I assembled db 0x62, 0x2c, 0x24 with NASM and linked it with ld -melf_i386 into a 32-bit ELF executable (because I have a wrapper assemble+link+disassemble 比 just assemble).
更容易的脚本
objdump -drwC -Mintel
8048060: 62 2c 24 bound ebp,QWORD PTR [esp]
objdump -drwC -Matt
8048060: 62 2c 24 bound %ebp,(%esp)
这似乎是 binutils (as / objdump / gdb) 中实现的 AT&T 语法的一个怪癖 bound 要求首先列出寄存器参数。
bound %eax, (%edx) # assembles fine
bound (%edx), %eax # foo.s:2: Error: operand size mismatch for `bound'
我假设在 Intel 语法模式下要求寄存器 arg 是第一个是相同的。这里的意思没有歧义，只是一个奇怪的设计选择，不颠倒操作数与 Intel 语法。
相关：AT&T syntax also has "bugs" according to the GAS manual:
9.15.16 AT&T Syntax bugs
The UnixWare assembler, and probably other AT&T derived ix86 Unix assemblers, generate floating point instructions with reversed source and destination registers in certain cases. Unfortunately, gcc and possibly many other programs use this reversed syntax, so we’re stuck with it.
For example
fsub %st,%st(3)
results in %st(3) being updated to %st - %st(3) rather than the expected %st(3) - %st. This happens with all the non-commutative arithmetic floating point operations with two register operands where the source register is %st and the destination register is %st(i).
因此 AT&T 语法存在实际错误，其中两个命令都有效并且意味着 不同 事物。我认为我们可以将这个操作数“反转”归为一组。
ndisasm -b32 disassemble 为 622C24 bound ebp,[esp]，符合 Intel 手册的操作数顺序。
关于字节模式622c24，有2种情况。
第一种情况：objdump - as 对。
objdump反汇编622c24为：bound %ebp,(%esp)- linux
as将bound %ebp,(%esp)汇编为：622c24
第二种情况：库 Capstone- keystone 对。
Capstone反汇编622c24为：bound (%esp), %ebpKeystone将bound (%esp), %ebp汇编为：622c24
正如您在上面看到的，源和目标的位置颠倒了。
- objdump :
bound %ebp,(%esp) - 顶点：
bound (%esp), %ebp
根据 AT&T 语法，BOUND r32, m32 是正确的。
因此，这意味着 Capstone-keystone pare 是正确的。
问。那么，objdump-as反汇编bound指令有问题吗？
是不是binutils的bug？
是的，这可能是 AT&T 语法中的一个设计错误。它们通常遵循从 Intel 语法反转操作数的模式，并重命名 sign/zero-extension 助记符（cdq => cltq、movsx eax, byte[mem] => movsbl） .与此的偏差可视为设计错误。
但不是实现错误，除非旧版本不同。当 AT&T 随心所欲并为不同的指令制定自己的规则时，这是有效的（但令人不快）。这可能是与原始 Unixware assembler 兼容的另一种情况。 （见下文）。
The bound instruction 不写入任何一个输入操作数 ，因此两者都不是真正的目的地。与 cmp 不同的是，操作数顺序没有任何意义。它只是根据 upper/lower 边界检查寄存器，如果超出边界则引发 #BR 异常。
它只有一个操作码，它需要寄存器 + 内存操作数（在 ModR/M r 和 r/m 字段中。
objdump -d 在 AT&T 和 Intel 语法中首先列出寄存器操作数。
I assembled db 0x62, 0x2c, 0x24 with NASM and linked it with ld -melf_i386 into a 32-bit ELF executable (because I have a wrapper assemble+link+disassemble 比 just assemble).
objdump -drwC -Mintel
8048060: 62 2c 24 bound ebp,QWORD PTR [esp]
objdump -drwC -Matt
8048060: 62 2c 24 bound %ebp,(%esp)
这似乎是 binutils (as / objdump / gdb) 中实现的 AT&T 语法的一个怪癖 bound 要求首先列出寄存器参数。
bound %eax, (%edx) # assembles fine
bound (%edx), %eax # foo.s:2: Error: operand size mismatch for `bound'
我假设在 Intel 语法模式下要求寄存器 arg 是第一个是相同的。这里的意思没有歧义，只是一个奇怪的设计选择，不颠倒操作数与 Intel 语法。
相关：AT&T syntax also has "bugs" according to the GAS manual:
9.15.16 AT&T Syntax bugs
The UnixWare assembler, and probably other AT&T derived ix86 Unix assemblers, generate floating point instructions with reversed source and destination registers in certain cases. Unfortunately, gcc and possibly many other programs use this reversed syntax, so we’re stuck with it.
For example
fsub %st,%st(3)results in
%st(3)being updated to%st - %st(3)rather than the expected%st(3) - %st. This happens with all the non-commutative arithmetic floating point operations with two register operands where the source register is%stand the destination register is%st(i).
因此 AT&T 语法存在实际错误，其中两个命令都有效并且意味着 不同 事物。我认为我们可以将这个操作数“反转”归为一组。
ndisasm -b32 disassemble 为 622C24 bound ebp,[esp]，符合 Intel 手册的操作数顺序。