On 04/10/2014 03:57 PM, 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. :)
That's good that we decode it correctly, but there is more to it. Call insn pushes return address to stack. This "mutant 16-bit call", what should it push? Full RIP? Truncated 16-bit IP? If yes, by how much does it advance RSP? +2? +8? Hmm. Does it affect RSP or only its 16-bit lower part? It's a can of worms! :) -- 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/