On 04/17/2014 08:40 PM, Masami Hiramatsu wrote:
> (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...
>
What it sounds like it really wants is a "bitwise" flag on the instruction.
-hpa
--
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/
