(2014/04/11 2:02), Denys Vlasenko wrote: >> The (f64) modifier in x86-opcode-map.txt means that inat_is_force64() >> is true for call opcode. So we won't reach "case 2:" in __get_immv32(): >> insn_get_prefixes() did set insn->opnd_bytes to 2 when it saw 0x66 prefix, >> but it was before we reach this place, and here we overrode it. >> This is a bug in insn decoder. > > I tested it on both Intel and AMD CPUs and my worst fears came true: > this instruction has different widths on different CPUs. > > This program: > > # compile with: gcc -nostartfiles -nostdlib -o int3 int3.S > _start: .globl _start > .byte 0x66,0xe9,0,0 > .byte 0,0 > 1: jmp 1b > > compiles to this: > > 00000000004000b0 <_start>: > 4000b0: 66 e9 00 00 jmpw b4 <_start-0x3ffffc> > 4000b4: 00 00 add %al,(%rax) > 4000b6: eb fe jmp 4000b6 <_start+0x6> > > and it will reach 0x4000b6 on Intel CPU. > IOW, Intel SandyBridge CPU thinks that insn is in fact 66 e9 00 00 00 00, > no RIP truncation occurs. > > On AMD K10 CPU, the very same binary jumps to 0x00b4 > and gets SIGSEGV with MAPERR. > AMD thinks that the insn is 66 e9 00 00 as shown above.
Hmm, interesting. > Thus, insn.c decoder implements Intel's idea of this insn > while binutils (objdump, gdb) implement AMD decode. Yeah, insn.c relays on intel's opcode map. > This same program can be compiled to 32-bit code, > in this mode both CPUs treat insn as 66 e9 00 00. In 32 bit mode, insn.c treats it as 66 e9 00 00 correctly. > Oleg, I'm sure you are very sympathetic by now to the idea > of just not supporting this insn at all. ;) > > You can check whether insn had any prefix by checking > insn->prefixes->nbytes != 0... No, since there are other prefixes (and it may be meaningless) you should find 0x66 in insn->prefixes->bytes[]. > ..but there is a problem with that. P4 introduced branch hints, > which are implemented using segment prefixes on conditional jumps. > Meaning that some compilers produce > > 2e 0f 82 nn nn nn nn > > as (hint not taken) JB <offset32> insn. > > 2e is CS segment prefix. insn->prefixes->nbytes == 1 for this insn. > DS prefix (3e) hints that branch is taken. > > They were nearly useless on P4 anyway and ignored by all CPUs > before or since, but they can be seen in some programs. Hm, this could be done. > > Looks like we'll need this: > > /* > * 16-bit overrides such as CALLW (66 e8 nn nn) are not supported. > * Intel and AMD behavior differ in 64-bit mode: Intel ignores 66 prefix. > * No one uses these insns. > * To filter them out, reject any branch insns with prefixes... > */ > if (insn->prefixes->nbytes > 1) > bail_out; As I said above, check insn->prefixes.bytes[0..nbytes]. > /* > * ...Except a single 3e or 2e "branch taken/not taken" hint prefix. > * These are (rarely) used, but ignored by any CPU except P4. > * Example: 2e 0f 82 nn nn nn nn is JB,PN <offset32> > */ > if (insn->prefixes->nbytes == 1 && (insn->prefixes->bytes[0] | 0x10) != 0x3e)) > bail_out; > Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
