(2014/04/18 2:31), Sasha Levin wrote: >> I also have seen several attempts at using the generic instruction >> decoder which has resulted in more complexity, not less, because of >> excess generality, so it is not an obvious thing. > > Let's split this patchset into two: > > We have one part which moves kmemcheck to the generic instruction decoder > and adds memory access size to the instruction decoder. There seems to be > no objection to that part beyond technical issues regarding how we store > the new size value.
This looks OK to me. > The other part is adding mnemonics to the instruction decoder. If my > explanation above makes sense, and kmemcheck does need to know about AND, > OR, XOR, MOVS and CMPS then let me know how to proceed about changing > the instruction decoder to add that functionality. I don't think we need to add such things to instruction decoder. You'd better start from clarifying the bit pattern of those instructions and making macros or inlines which evaluate insn->opcode.value. Using automatic generated macros for immediate in the source code always leads misunderstanding and abuse, and is hard to fix if a bug is there. I strongly recommend you to define instruction classification macros for their use by hand. That's easy to review too. Actually x86 has a long history and its mnemonics are not so simple... Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research 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/
