(2014/04/10 23:28), Oleg Nesterov wrote: > On 04/10, Masami Hiramatsu wrote: >> >> (2014/04/10 22:41), Denys Vlasenko wrote: >>> On 04/09/2014 05:43 PM, Oleg Nesterov wrote: >>>> On 04/08, Jim Keniston wrote: >>>>> >>>>> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote: >>>>>> 0xe8. Anything else? >>>>> >>>>> No, I think e8 is the only call instruction uprobes will see. >>>> >>>> Good. >>> >>> There is this monstrosity, "16-bit override for branches" in 64-mode: >>> >>> 66 e8 nn nn callw <offset16> >>> >>> Nobody sane uses it because it truncates instruction pointer. >> >> No problem, insn.c can handle that too. :) > > Does it? > > "callw 1f; 1:\n" > "rep; nop\n" > > objdump: > > 66 e8 00 00 callw 485 <_init-0x3ffed3> > f3 90 pause > > > if we probe this "callw", we copy MAX_INSN_BYTES into auprobe->insn, > and after insn_get_length() (insn_complete() == T) > > // this is correct > OPCODE1() == e8 > > // this all looks wrong > insn->length == 6 > insn->immediate.value == -1863122944 > insn->immediate.nbytes == 4
Oops, that should be a bug in insn.c! I'll fix that asap! Thank you, > > so it seems that lib/insn.c treats the next "pause" insn as the high > 16 bits of address. > > Oleg. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
