Created attachment 7254 [details] mulsd objdump provide wrond disassemble for mulsd instruction. opcode 0xf2, 0x66, 0x0f, 0x59, 0xff represent the mulsd %%xmm7, %%xmm7 instruction but objdump detect it as f2 data16 66 0f 59 ff mulpd %xmm7,%xmm7 Attached file shows that this opcode corresponds to mulsd instruction in the real hardware. > gcc -m64 -O0 -Wall mulsd.c > ./a.out 4.000000 2.000000 > objdump -v GNU objdump (GNU Binutils) 2.23.2
The problem is present not just for MULSD but for many x86 instructions that are encoded with a mandatory prefix (e.g. 0xF2), but also are allowed to have optional prefixes like 0x66 to be inserted between opcode and mandatory prefix. Hardware does not pay attention to prefixes order.
(In reply to Grigory Rechistov from comment #1) > The problem is present not just for MULSD but for many x86 instructions that > are encoded with a mandatory prefix (e.g. 0xF2), but also are allowed to > have optional prefixes like 0x66 to be inserted between opcode and mandatory > prefix. Hardware does not pay attention to prefixes order. Little correction. Harware look at prefixes order but not in all cases. Examples with mul** instructions: 66 f3 f2 0f 59 ff is mulsd %%xmm7, %%xmm7 (mandatory prefix is f2) 66 f2 f3 0f 59 ff is mulss %%xmm7, %%xmm7 (mandatory prefix is f3) 66 0f 59 ff is mulpd %%xmm7, %%xmm7 (mandatory prefix is 66) f2 66 0f 59 ff is mulsd %%xmm7, %%xmm7 (mandatory prefix is f2) If both f2 and f3 prefixes present last of it is mandatory. But 66 prefix is mandatory only if f2 and f3 prefixes is not present in this insturction.
*** Bug 16089 has been marked as a duplicate of this bug. ***
Isn't this effectively (despite being older) a duplicate of 16893, and hence has been fixed along long ago, with that other report?