Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Tue, 2017-06-06 at 13:58 +0200, Borislav Petkov wrote:
> On Mon, Jun 05, 2017 at 11:06:58PM -0700, Ricardo Neri wrote:
> > I agree that insn-eval reads somewhat funny. I did not want to go with
> > insn-dec.c as insn.c, in my opinion, already decodes the instruction
> > (i.e., it finds prefixes, opcodes, ModRM, SIB and displacement bytes).
> > In insn-eval.c I simply take those decoded parameters and evaluate them
> > to obtain the values they contain (e.g., a specific memory location).
> > Perhaps, insn-resolve.c could be a better name? Or maybe isnn-operands?
> So actually I'm gravitating towards calling all that instruction
> "massaging" code with a single prefix to denote this comes from the insn
> decoder/handler/whatever...
> I.e.,
> 	"insn-decoder: x86: invalid register type"
> or
> 	"inat: x86: invalid register type"
> or something to that effect.
> I mean, If we're going to grow our own - as we do, apparently - maybe it
> all should be a separate entity with its proper name.

I see. You were more concerned about the naming of the coding artifacts
(e.g., function names, error prints, etc) than the actual filenames. I
think I have aligned with the function naming of insn.c in all the
functions that are exposed via header by using the inns_ prefix. For
static functions I don't use that prefix. Perhaps I can use the __
prefix as insn.c does.

Thanks and BR,

To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Linux Console]     [Linux Audio]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Camping]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Samba]     [Linux Media]     [Fedora Users]

  Powered by Linux