[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53509EB9.5070001@hitachi.com>
Date: Fri, 18 Apr 2014 12:40:41 +0900
From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To: Sasha Levin <sasha.levin@...cle.com>
Cc: "H. Peter Anvin" <hpa@...or.com>, vegard.nossum@...cle.com,
penberg@...nel.org, jamie.iles@...cle.com, mingo@...hat.com,
tglx@...utronix.de, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] x86/insn: Extract more information about instructions
(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.pt@...achi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists