From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3335 invoked by alias); 7 Aug 2012 14:02:23 -0000 Received: (qmail 3319 invoked by uid 22791); 7 Aug 2012 14:02:21 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Aug 2012 14:02:08 +0000 Received: by vcbfl10 with SMTP id fl10so4667530vcb.0 for ; Tue, 07 Aug 2012 07:02:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.12.7 with SMTP id u7mr7180548veb.8.1344348127850; Tue, 07 Aug 2012 07:02:07 -0700 (PDT) Received: by 10.58.165.104 with HTTP; Tue, 7 Aug 2012 07:02:07 -0700 (PDT) In-Reply-To: <5021389B0200007800093459@nat28.tlf.novell.com> References: <500EDB2202000078000903AF@nat28.tlf.novell.com> <50210AD602000078000932B3@nat28.tlf.novell.com> <5021389B0200007800093459@nat28.tlf.novell.com> Date: Tue, 07 Aug 2012 14:03:00 -0000 Message-ID: Subject: Re: [PATCH, v2] x86-64: correct segment override prefix generation From: "H.J. Lu" To: Jan Beulich Cc: binutils@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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/msg00133.txt.bz2 On Tue, Aug 7, 2012 at 6:47 AM, Jan Beulich wrote: >>>> 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 +0200 >>> +++ 2012-08-07/gas/config/tc-i386.c 2012-08-07 12:13:39.000000000 +0200 >>> @@ -5729,18 +5729,14 @@ build_modrm_byte (void) >>> i.sib.base = i.base_reg->reg_num; >>> /* x86-64 ignores REX prefix bit here to avoid decoder >>> complications. */ >>> - if ((i.base_reg->reg_num & 7) == EBP_REG_NUM) >>> - { >>> + if (!(i.base_reg->reg_flags & RegRex) >>> + && (i.base_reg->reg_num == EBP_REG_NUM >>> + || i.base_reg->reg_num == ESP_REG_NUM)) >>> default_seg = &ss; >>> - if (i.disp_operands == 0) >>> - { >>> - fake_zero_displacement = 1; >>> - i.types[op].bitfield.disp8 = 1; >>> - } >>> - } >>> - else if (i.base_reg->reg_num == ESP_REG_NUM) >>> + if (i.base_reg->reg_num == 5 && i.disp_operands == 0) >> >> 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. > OK then. Thanks. -- H.J.