From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29769 invoked by alias); 7 Aug 2012 13:47:56 -0000 Received: (qmail 29756 invoked by uid 22791); 7 Aug 2012 13:47:55 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Aug 2012 13:47:42 +0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 07 Aug 2012 14:47:41 +0100 Message-Id: <5021389B0200007800093459@nat28.tlf.novell.com> Date: Tue, 07 Aug 2012 13:56:00 -0000 From: "Jan Beulich" To: "H.J. Lu" Cc: Subject: Re: [PATCH, v2] x86-64: correct segment override prefix generation References: <500EDB2202000078000903AF@nat28.tlf.novell.com> <50210AD602000078000932B3@nat28.tlf.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00131.txt.bz2 >>> On 07.08.12 at 15:44, "H.J. Lu" wrote: > On Tue, Aug 7, 2012 at 3:32 AM, Jan Beulich wrote: >>>>> On 30.07.12 at 19:03, "H.J. Lu" wrote: >>> Please provide a testcase to show the correct behavior. >> >> Here you go. >> >> Jan >> >> Despite them being ignored by the CPU, gas issues segment override >> prefixes for other than FS/GS in 64-bit mode. If doing so at all, it >> should clearly do this correctly. Determining the default segment, >> however, requires to take into consideration RegRex (so far, RSP, RBP, >> R12, and R13 were all treated equally here). >> >> gas/ >> 2012-08-07 Jan Beulich >> * config/tc-i386-intel.c (build_modrm_byte): Split determining >> default segment from figuring out encoding. Honor RegRex for >> the former. >> >> gas/testsuite/ >> 2012-08-07 Jan Beulich >> >> * gas/i386/x86-64-segovr.{s,l}: New. >> * gas/i386/i386.exp: Run new test. >> >> --- 2012-08-07/gas/config/tc-i386.c 2012-07-31 09:45:03.000000000 +0= 200 >> +++ 2012-08-07/gas/config/tc-i386.c 2012-08-07 12:13:39.000000000 +0= 200 >> @@ -5729,18 +5729,14 @@ build_modrm_byte (void) >> i.sib.base =3D i.base_reg->reg_num; >> /* x86-64 ignores REX prefix bit here to avoid decoder >> complications. */ >> - if ((i.base_reg->reg_num & 7) =3D=3D EBP_REG_NUM) >> - { >> + if (!(i.base_reg->reg_flags & RegRex) >> + && (i.base_reg->reg_num =3D=3D EBP_REG_NUM >> + || i.base_reg->reg_num =3D=3D ESP_REG_NUM)) >> default_seg =3D &ss; >> - if (i.disp_operands =3D=3D 0) >> - { >> - fake_zero_displacement =3D 1; >> - i.types[op].bitfield.disp8 =3D 1; >> - } >> - } >> - else if (i.base_reg->reg_num =3D=3D ESP_REG_NUM) >> + if (i.base_reg->reg_num =3D=3D 5 && i.disp_operands =3D=3D= 0) >=20 > Please use EBP_REG_NUM instead 5 here. But that change was intentional - we're _not_ looking for EBP here, we're looking for "EBP or R13". The previous use of EBP_REG_NUM was part of why this was broken imo. > OK with the EBP_REG_NUM change above if Linux x86-64 kernel > compiles and runs. Sure, that has been the case for many weeks already. Jan