From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [PATCH -tip v14 01/12] x86: instruction decoder API Date: Thu, 20 Aug 2009 22:14:34 +0200 Message-ID: <20090820201432.GB6078@nowhere> References: <20090813203403.31965.20973.stgit@localhost.localdomain> <20090813203413.31965.49709.stgit@localhost.localdomain> <20090819234227.GJ4972@nowhere> <20090820002113.GK4972@nowhere> <4A8D65CC.8030205@redhat.com> <20090820152549.GD6389@nowhere> <4A8D76C5.9060008@redhat.com> <20090820180737.GA6229@nowhere> <4A8D9D85.50809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Ingo Molnar , Steven Rostedt , lkml , systemtap , kvm , DLE , Jim Keniston , "H. Peter Anvin" , Ananth N Mavinakayanahalli , Avi Kivity , Andi Kleen , Christoph Hellwig , "Frank Ch. Eigler" , Jason Baron , "K.Prasad" , Lai Jiangshan , Li Zefan , =?utf-8?B?UHJ6ZW15c8WCYXdQYXdlxYJjenlr?= , Roland McGrath , Sam Ravnborg , Srikar Dronamraju , Tom Zanussi , Vegard Nossum To: Masami Hiramatsu Return-path: Received: from mail-ew0-f207.google.com ([209.85.219.207]:41669 "EHLO mail-ew0-f207.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751735AbZHTUOi (ORCPT ); Thu, 20 Aug 2009 16:14:38 -0400 Content-Disposition: inline In-Reply-To: <4A8D9D85.50809@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Aug 20, 2009 at 03:01:25PM -0400, Masami Hiramatsu wrote: > Frederic Weisbecker wrote: >> On Thu, Aug 20, 2009 at 12:16:05PM -0400, Masami Hiramatsu wrote: >>> Frederic Weisbecker wrote: >>>> On Thu, Aug 20, 2009 at 11:03:40AM -0400, Masami Hiramatsu wrote: >>>>> Frederic Weisbecker wrote: >>>>>> On Thu, Aug 20, 2009 at 01:42:31AM +0200, Frederic Weisbecker wr= ote: >>>>>>> On Thu, Aug 13, 2009 at 04:34:13PM -0400, Masami Hiramatsu wrot= e: >>>>>>>> Add x86 instruction decoder to arch-specific libraries. This d= ecoder >>>>>>>> can decode x86 instructions used in kernel into prefix, opcode= , modrm, >>>>>>>> sib, displacement and immediates. This can also show the lengt= h of >>>>>>>> instructions. >>>>>>>> >>>>>>>> This version introduces instruction attributes for decoding in= structions. >>>>>>>> The instruction attribute tables are generated from the opcode= map file >>>>>>>> (x86-opcode-map.txt) by the generator script(gen-insn-attr-x86= =2Eawk). >>>>>>>> >>>>>>>> Currently, the opcode maps are based on opcode maps in Intel(R= ) 64 and >>>>>>>> IA-32 Architectures Software Developers Manual Vol.2: Appendix= =2EA, >>>>>>>> and consist of below two types of opcode tables. >>>>>>>> >>>>>>>> 1-byte/2-bytes/3-bytes opcodes, which has 256 elements, are >>>>>>>> written as below; >>>>>>>> >>>>>>>> Table: table-name >>>>>>>> Referrer: escaped-name >>>>>>>> opcode: mnemonic|GrpXXX [operand1[,operand2...]] [(extra1)= [,(extra2)...] [| 2nd-mnemonic ...] >>>>>>>> (or) >>>>>>>> opcode: escape # escaped-name >>>>>>>> EndTable >>>>>>>> >>>>>>>> Group opcodes, which has 8 elements, are written as below; >>>>>>>> >>>>>>>> GrpTable: GrpXXX >>>>>>>> reg: mnemonic [operand1[,operand2...]] [(extra1)[,(extra2= )...] [| 2nd-mnemonic ...] >>>>>>>> EndTable >>>>>>>> >>>>>>>> These opcode maps include a few SSE and FP opcodes (for setup)= , because >>>>>>>> those opcodes are used in the kernel. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I'm getting the following build error on an old K7 box: >>>>>>> >>>>>>> arch/x86/lib/inat.c: In function =E2=80=98inat_get_opcode_attri= bute=E2=80=99: >>>>>>> arch/x86/lib/inat.c:29: erreur: =E2=80=98inat_primary_table=E2=80= =99 undeclared (first use in this function) >>>>>>> arch/x86/lib/inat.c:29: erreur: (Each undeclared identifier is = reported only once >>>>>>> arch/x86/lib/inat.c:29: erreur: for each function it appears in= =2E) >>>>>>> >>>>>>> >>>>>>> I've attached my config. I haven't such problem on a dual x86-6= 4 box. >>>>>> >>>>>> >>>>>> Actually I have the same problem in x86-64 >>>>>> The content of my arch/x86/lib/inat-tables.c: >>>>>> >>>>>> /* x86 opcode map generated from x86-opcode-map.txt */ >>>>>> /* Do not change this code. */ >>>>>> /* Table: one byte opcode */ >>>>>> /* Escape opcode map array */ >>>>>> const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX + 1][IN= AT_LPREFIX_MAX + 1] =3D { >>>>>> }; >>>>>> >>>>>> /* Group opcode map array */ >>>>>> const insn_attr_t const *inat_group_tables[INAT_GRP_MAX + 1][INA= T_LPREFIX_MAX + 1] =3D { >>>>>> }; >>>>>> >>>>>> >>>>>> I guess there is a problem with the generation of this file. >>>>> >>>>> Aah, you may use mawk on Ubuntu 9.04, right? >>>>> If so, unfortunately, mawk is still under development. >>>>> >>>>> http://invisible-island.net/mawk/CHANGES >>>> >>>> >>>> >>>> Aargh... >>>> >>>> >>>>>> 20090727 >>>>>> add check/fix to prevent gsub from recurring to modify on a sub= string >>>>>> of the current line when the regular expression is anchored to = the >>>>>> beginning of the line; fixes gawk's anchgsub testcase. >>>>>> >>>>>> add check for implicit concatenation mistaken for exponent; fix= es >>>>>> gawk's hex testcase. >>>>>> >>>>>> add character-classes to built-in regular expressions. >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> Look, this means we can't use char-class expressions like >>>>> [:lower:] until this version... >>>>> >>>>> And I've found another bug in mawk-1.3.3-20090728(the latest one)= =2E >>>>> it almost works, but; >>>>> >>>>> $ mawk 'BEGIN {printf("0x%x\n", 0)}' >>>>> 0x1 >>>> >>>> >>>> Ouch, indeed. >>>> >>>> >>>> >>>>> $ gawk 'BEGIN {printf("0x%x\n", 0)}' >>>>> 0x0 >>>>> >>>>> This bug skips an array element index 0x0 in inat-tables.c :( >>>>> >>>>> So, I recommend you to install gawk instead mawk until that >>>>> supports all posix-awk features, since I don't think it is >>>>> good idea to avoid all those bugs which depends on >>>>> implementation (not specification). >>>>> >>>>> >>>>> Thank you, >>>> >>>> >>>> >>>> Yeah, indeed. May be add a warning (or build error) in case the us= er uses >>>> mawk? >>> >>> Hmm, it is possible that mawk will fix those bugs and catch up soon= , >>> so, I think checking mawk is not a good idea. >>> (and since there will be other awk implementations, it's not fair.) >>> >>> I think what all I can do now is reporting bugs to >>> mawk and ubuntu people.:-) >> >> >> >> Yeah, but without your tip I couldn't be able to find the origin >> before some time. >> And the kernel couldn't build anyway. >> >> At least we should do something with this version of mawk. > > Hm, indeed. > Maybe, we can run additional sanity check script before using > awk, like this; > > --- > res=3D`echo a | $AWK '/[[:lower:]]+/{print "OK"}'` > [ "$res" !=3D "OK" ] && exit 1 > > res=3D`$AWK 'BEGIN {printf("%x", 0)}'` > [ "$res" !=3D "0" ] && exit 1 > > exit 0 > --- > > Thanks, > Yeah, that looks good. Thanks.