x86: Don't display eiz with no scale

Message ID CAMe9rOodx4xXeeW53hv_v9bvONRh=LWMs1EM7y80wJfuhvaKiA@mail.gmail.com
State New
Headers show
Series
  • x86: Don't display eiz with no scale
Related show

Commit Message

David Faust via Binutils July 15, 2020, 1:57 p.m.
On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 14.07.2020 18:54, H.J. Lu wrote:

> > On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <hjl.tools@gmail.com> wrote:

> >>

> >> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>

> >>> On 14.07.2020 14:43, H.J. Lu wrote:

> >>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was

> >>>>> broken with the code present:

> >>>>>

> >>>>>         addr32 mov $0x89abcdef, %rax

> >>>>>

> >>>>> would have got the immediate sign-extended from 32 to 64 bits.

> >>>>>

> >>>>

> >>>> I opened:

> >>>>

> >>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237

> >>>>

> >>>> There are multiple issues.

> >>>

> >>> Hmm, the former two lines there look correct to me, while the latter

> >>> two lines look to have been translated with a gas that didn't have

> >>> yesterday's change yet. IOW - I'm somewhat confused.

> >>

> >> The bug is against binutils 2.35, not master.

> >>

> >

> > Here is the patch for master branch.

>

> Ah, so your issue was just with disassembly. Yet then why not go a step

> further and (at least in 64-bit mode) print

>

> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef

> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211

>

> instead of

>

> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)

> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)

>

> and keep the () part only for

>

> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)

>

> , as there's no SIB-less way to express a base-and-index-less address?

>


Done.

I am checking in this.

-- 
H.J.

Comments

Jan Beulich July 21, 2020, 9:40 a.m. | #1
On 15.07.2020 15:57, H.J. Lu wrote:
> On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 14.07.2020 18:54, H.J. Lu wrote:

>>> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <hjl.tools@gmail.com> wrote:

>>>>

>>>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>

>>>>> On 14.07.2020 14:43, H.J. Lu wrote:

>>>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was

>>>>>>> broken with the code present:

>>>>>>>

>>>>>>>         addr32 mov $0x89abcdef, %rax

>>>>>>>

>>>>>>> would have got the immediate sign-extended from 32 to 64 bits.

>>>>>>>

>>>>>>

>>>>>> I opened:

>>>>>>

>>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237

>>>>>>

>>>>>> There are multiple issues.

>>>>>

>>>>> Hmm, the former two lines there look correct to me, while the latter

>>>>> two lines look to have been translated with a gas that didn't have

>>>>> yesterday's change yet. IOW - I'm somewhat confused.

>>>>

>>>> The bug is against binutils 2.35, not master.

>>>>

>>>

>>> Here is the patch for master branch.

>>

>> Ah, so your issue was just with disassembly. Yet then why not go a step

>> further and (at least in 64-bit mode) print

>>

>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef

>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211

>>

>> instead of

>>

>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)

>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)

>>

>> and keep the () part only for

>>

>> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)

>>

>> , as there's no SIB-less way to express a base-and-index-less address?

>>

> 

> Done.

> 

> I am checking in this.


Having only now noticed the collision with my change to
evex-no-scale-64.d, I wonder whether we want to revert your change,
and hence whether my underlying suggestion was a bad one: There's
now no sign left that these insns use 32-bit address mode. The
alternative would be to ensure that an addr32 prefix gets emitted.
I'd personally favor this alternative, but I could live with the
revert. (When making the suggestion I didn't realize this is a
32-bit-addressing-specific output mode.)

Jan
David Faust via Binutils July 21, 2020, 11:29 a.m. | #2
On Tue, Jul 21, 2020 at 2:40 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 15.07.2020 15:57, H.J. Lu wrote:

> > On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 14.07.2020 18:54, H.J. Lu wrote:

> >>> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <hjl.tools@gmail.com> wrote:

> >>>>

> >>>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>

> >>>>> On 14.07.2020 14:43, H.J. Lu wrote:

> >>>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was

> >>>>>>> broken with the code present:

> >>>>>>>

> >>>>>>>         addr32 mov $0x89abcdef, %rax

> >>>>>>>

> >>>>>>> would have got the immediate sign-extended from 32 to 64 bits.

> >>>>>>>

> >>>>>>

> >>>>>> I opened:

> >>>>>>

> >>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237

> >>>>>>

> >>>>>> There are multiple issues.

> >>>>>

> >>>>> Hmm, the former two lines there look correct to me, while the latter

> >>>>> two lines look to have been translated with a gas that didn't have

> >>>>> yesterday's change yet. IOW - I'm somewhat confused.

> >>>>

> >>>> The bug is against binutils 2.35, not master.

> >>>>

> >>>

> >>> Here is the patch for master branch.

> >>

> >> Ah, so your issue was just with disassembly. Yet then why not go a step

> >> further and (at least in 64-bit mode) print

> >>

> >> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef

> >> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211

> >>

> >> instead of

> >>

> >> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)

> >> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)

> >>

> >> and keep the () part only for

> >>

> >> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)

> >>

> >> , as there's no SIB-less way to express a base-and-index-less address?

> >>

> >

> > Done.

> >

> > I am checking in this.

>

> Having only now noticed the collision with my change to

> evex-no-scale-64.d, I wonder whether we want to revert your change,

> and hence whether my underlying suggestion was a bad one: There's

> now no sign left that these insns use 32-bit address mode. The

> alternative would be to ensure that an addr32 prefix gets emitted.

> I'd personally favor this alternative, but I could live with the

> revert. (When making the suggestion I didn't realize this is a

> 32-bit-addressing-specific output mode.)

>


Can you revert it for me?

Thanks.

-- 
H.J.
Jan Beulich July 21, 2020, 12:22 p.m. | #3
On 21.07.2020 13:29, H.J. Lu wrote:
> On Tue, Jul 21, 2020 at 2:40 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 15.07.2020 15:57, H.J. Lu wrote:

>>> On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 14.07.2020 18:54, H.J. Lu wrote:

>>>>> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <hjl.tools@gmail.com> wrote:

>>>>>>

>>>>>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>>

>>>>>>> On 14.07.2020 14:43, H.J. Lu wrote:

>>>>>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was

>>>>>>>>> broken with the code present:

>>>>>>>>>

>>>>>>>>>         addr32 mov $0x89abcdef, %rax

>>>>>>>>>

>>>>>>>>> would have got the immediate sign-extended from 32 to 64 bits.

>>>>>>>>>

>>>>>>>>

>>>>>>>> I opened:

>>>>>>>>

>>>>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237

>>>>>>>>

>>>>>>>> There are multiple issues.

>>>>>>>

>>>>>>> Hmm, the former two lines there look correct to me, while the latter

>>>>>>> two lines look to have been translated with a gas that didn't have

>>>>>>> yesterday's change yet. IOW - I'm somewhat confused.

>>>>>>

>>>>>> The bug is against binutils 2.35, not master.

>>>>>>

>>>>>

>>>>> Here is the patch for master branch.

>>>>

>>>> Ah, so your issue was just with disassembly. Yet then why not go a step

>>>> further and (at least in 64-bit mode) print

>>>>

>>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef

>>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211

>>>>

>>>> instead of

>>>>

>>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)

>>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)

>>>>

>>>> and keep the () part only for

>>>>

>>>> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)

>>>>

>>>> , as there's no SIB-less way to express a base-and-index-less address?

>>>>

>>>

>>> Done.

>>>

>>> I am checking in this.

>>

>> Having only now noticed the collision with my change to

>> evex-no-scale-64.d, I wonder whether we want to revert your change,

>> and hence whether my underlying suggestion was a bad one: There's

>> now no sign left that these insns use 32-bit address mode. The

>> alternative would be to ensure that an addr32 prefix gets emitted.

>> I'd personally favor this alternative, but I could live with the

>> revert. (When making the suggestion I didn't realize this is a

>> 32-bit-addressing-specific output mode.)

>>

> 

> Can you revert it for me?


Done.

Jan
David Faust via Binutils July 21, 2020, 2:01 p.m. | #4
On Tue, Jul 21, 2020 at 5:22 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 21.07.2020 13:29, H.J. Lu wrote:

> > On Tue, Jul 21, 2020 at 2:40 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 15.07.2020 15:57, H.J. Lu wrote:

> >>> On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> On 14.07.2020 18:54, H.J. Lu wrote:

> >>>>> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <hjl.tools@gmail.com> wrote:

> >>>>>>

> >>>>>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>>

> >>>>>>> On 14.07.2020 14:43, H.J. Lu wrote:

> >>>>>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was

> >>>>>>>>> broken with the code present:

> >>>>>>>>>

> >>>>>>>>>         addr32 mov $0x89abcdef, %rax

> >>>>>>>>>

> >>>>>>>>> would have got the immediate sign-extended from 32 to 64 bits.

> >>>>>>>>>

> >>>>>>>>

> >>>>>>>> I opened:

> >>>>>>>>

> >>>>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237

> >>>>>>>>

> >>>>>>>> There are multiple issues.

> >>>>>>>

> >>>>>>> Hmm, the former two lines there look correct to me, while the latter

> >>>>>>> two lines look to have been translated with a gas that didn't have

> >>>>>>> yesterday's change yet. IOW - I'm somewhat confused.

> >>>>>>

> >>>>>> The bug is against binutils 2.35, not master.

> >>>>>>

> >>>>>

> >>>>> Here is the patch for master branch.

> >>>>

> >>>> Ah, so your issue was just with disassembly. Yet then why not go a step

> >>>> further and (at least in 64-bit mode) print

> >>>>

> >>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef

> >>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211

> >>>>

> >>>> instead of

> >>>>

> >>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)

> >>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)

> >>>>

> >>>> and keep the () part only for

> >>>>

> >>>> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)

> >>>>

> >>>> , as there's no SIB-less way to express a base-and-index-less address?

> >>>>

> >>>

> >>> Done.

> >>>

> >>> I am checking in this.

> >>

> >> Having only now noticed the collision with my change to

> >> evex-no-scale-64.d, I wonder whether we want to revert your change,

> >> and hence whether my underlying suggestion was a bad one: There's

> >> now no sign left that these insns use 32-bit address mode. The

> >> alternative would be to ensure that an addr32 prefix gets emitted.

> >> I'd personally favor this alternative, but I could live with the

> >> revert. (When making the suggestion I didn't realize this is a

> >> 32-bit-addressing-specific output mode.)

> >>

> >

> > Can you revert it for me?

>

> Done.


Thanks.

-- 
H.J.

Patch

From 4114f54845b24c01cf4f14bd02233047569194d4 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Wed, 15 Jul 2020 06:49:45 -0700
Subject: [PATCH] x86: Don't display eiz with no scale

Change

67 48 8b 1c 25 ef cd ab 89 	mov    0x89abcdef(,%eiz,1),%rbx

to

67 48 8b 1c 25 ef cd ab 89 	mov    0x89abcdef,%rbx

in AT&T syntax and

67 48 8b 1c 25 ef cd ab 89 	mov    rbx,QWORD PTR [eiz*1+0x89abcdef]

to

67 48 8b 1c 25 ef cd ab 89 	mov    rbx,QWORD PTR ds:0x89abcdef

in Intel syntax.

gas/

	PR gas/26237
	* testsuite/gas/i386/evex-no-scale-64.d: Updated.
	* testsuite/gas/i386/addr32.d: Likewise.
	* testsuite/gas/i386/x86-64-addr32-intel.d: Likewise.
	* testsuite/gas/i386/x86-64-addr32.d: Likewise.

opcodes/

	PR gas/26237
	* i386-dis.c (OP_E_memory): Don't display eiz with no scale
	without base nor index registers.
---
 gas/ChangeLog                                |  8 ++++++++
 gas/testsuite/gas/i386/evex-no-scale-64.d    |  2 +-
 gas/testsuite/gas/i386/x86-64-addr32-intel.d | 12 ++++++------
 gas/testsuite/gas/i386/x86-64-addr32.d       | 12 ++++++------
 opcodes/ChangeLog                            |  6 ++++++
 opcodes/i386-dis.c                           |  2 +-
 6 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/gas/ChangeLog b/gas/ChangeLog
index 194819eecf..2336fb57e1 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,11 @@ 
+2020-07-15  H.J. Lu  <hongjiu.lu@intel.com>
+
+	PR gas/26237
+	* testsuite/gas/i386/evex-no-scale-64.d: Updated.
+	* testsuite/gas/i386/addr32.d: Likewise.
+	* testsuite/gas/i386/x86-64-addr32-intel.d: Likewise.
+	* testsuite/gas/i386/x86-64-addr32.d: Likewise.
+
 2020-07-15  Nick Clifton  <nickc@redhat.com>
 
 	* write.c (create_note_reloc): Add desc2_size parameter.  Zero out
diff --git a/gas/testsuite/gas/i386/evex-no-scale-64.d b/gas/testsuite/gas/i386/evex-no-scale-64.d
index 33623656ee..6c9f68faf2 100644
--- a/gas/testsuite/gas/i386/evex-no-scale-64.d
+++ b/gas/testsuite/gas/i386/evex-no-scale-64.d
@@ -10,5 +10,5 @@  Disassembly of section .text:
  +[a-f0-9]+:	62 f1 7c 48 28 04 05 40 00 00 00 	vmovaps 0x40\(,%rax,1\),%zmm0
  +[a-f0-9]+:	62 f1 7c 48 28 04 25 40 00 00 00 	vmovaps 0x40,%zmm0
  +[a-f0-9]+:	67 62 f1 7c 48 28 04 05 40 00 00 00 	vmovaps 0x40\(,%eax,1\),%zmm0
- +[a-f0-9]+:	67 62 f1 7c 48 28 04 25 40 00 00 00 	vmovaps 0x40\(,%eiz,1\),%zmm0
+ +[a-f0-9]+:	67 62 f1 7c 48 28 04 25 40 00 00 00 	vmovaps 0x40,%zmm0
  +[a-f0-9]+:	62 f1 7c 48 28 04 25 40 00 00 00 	vmovaps 0x40,%zmm0
diff --git a/gas/testsuite/gas/i386/x86-64-addr32-intel.d b/gas/testsuite/gas/i386/x86-64-addr32-intel.d
index 0988457b34..7a25d40162 100644
--- a/gas/testsuite/gas/i386/x86-64-addr32-intel.d
+++ b/gas/testsuite/gas/i386/x86-64-addr32-intel.d
@@ -11,15 +11,15 @@  Disassembly of section .text:
 [ 	]*[a-f0-9]+:	67 48 8d 80 00 00 00 00[ 	]+lea[ 	]+rax,\[eax\+0x0\].*
 [ 	]*[a-f0-9]+:	67 49 8d 80 00 00 00 00[ 	]+lea[ 	]+rax,\[r8d\+0x0\].*
 [ 	]*[a-f0-9]+:	67 48 8d 05 00 00 00 00[ 	]+lea[ 	]+rax,\[eip\+0x0\].*
-[ 	]*[a-f0-9]+:	67 48 8d 04 25 00 00 00 00 	lea[ ]+rax,\[eiz\*1\+0x0\].*
+[ 	]*[a-f0-9]+:	67 48 8d 04 25 00 00 00 00 	lea[ ]+rax,ds:0x0	.*
 [ 	]*[a-f0-9]+:	67 a0 98 08 60 00    	addr32 mov al,ds:0x600898
 [ 	]*[a-f0-9]+:	67 66 a1 98 08 60 00 	addr32 mov ax,ds:0x600898
 [ 	]*[a-f0-9]+:	67 a1 98 08 60 00    	addr32 mov eax,ds:0x600898
 [ 	]*[a-f0-9]+:	67 48 a1 98 08 60 00 	addr32 mov rax,ds:0x600898
 [ 	]*[a-f0-9]+:	67 48 a1 98 08 80 00 	addr32 mov rax,ds:0x800898
-[ 	]*[a-f0-9]+:	67 48 8b 1c 25 98 08 80 00 	mov[ ]+rbx,QWORD PTR \[eiz\*1\+0x800898\]
+[ 	]*[a-f0-9]+:	67 48 8b 1c 25 98 08 80 00 	mov[ ]+rbx,QWORD PTR ds:0x800898
 [ 	]*[a-f0-9]+:	67 48 a1 ef cd ab 89 	addr32 mov rax,ds:0x89abcdef
-[ 	]*[a-f0-9]+:	67 48 8b 1c 25 ef cd ab 89 	mov[ ]+rbx,QWORD PTR \[eiz\*1\+0x89abcdef\]
+[ 	]*[a-f0-9]+:	67 48 8b 1c 25 ef cd ab 89 	mov[ ]+rbx,QWORD PTR ds:0x89abcdef
 [ 	]*[a-f0-9]+:	67 48 b8 ef cd ab 89 00 00 00 00 	addr32 movabs rax,0x89abcdef
 [ 	]*[a-f0-9]+:	67 48 bb ef cd ab 89 00 00 00 00 	addr32 movabs rbx,0x89abcdef
 [ 	]*[a-f0-9]+:	67 a2 98 08 60 00    	addr32 mov ds:0x600898,al
@@ -27,9 +27,9 @@  Disassembly of section .text:
 [ 	]*[a-f0-9]+:	67 a3 98 08 60 00    	addr32 mov ds:0x600898,eax
 [ 	]*[a-f0-9]+:	67 48 a3 98 08 60 00 	addr32 mov ds:0x600898,rax
 [ 	]*[a-f0-9]+:	67 48 a3 98 08 80 00 	addr32 mov ds:0x800898,rax
-[ 	]*[a-f0-9]+:	67 48 89 1c 25 98 08 80 00 	mov[ ]+QWORD PTR \[eiz\*1\+0x800898\],rbx
+[ 	]*[a-f0-9]+:	67 48 89 1c 25 98 08 80 00 	mov[ ]+QWORD PTR ds:0x800898,rbx
 [ 	]*[a-f0-9]+:	67 48 a3 ef cd ab 89 	addr32 mov ds:0x89abcdef,rax
-[ 	]*[a-f0-9]+:	67 48 89 1c 25 ef cd ab 89 	mov[ ]+QWORD PTR \[eiz\*1\+0x89abcdef\],rbx
-[ 	]*[a-f0-9]+:	67 89 04 25 11 22 33 ff 	mov[ ]+DWORD PTR \[eiz\*1\+0xff332211\],eax
+[ 	]*[a-f0-9]+:	67 48 89 1c 25 ef cd ab 89 	mov[ ]+QWORD PTR ds:0x89abcdef,rbx
+[ 	]*[a-f0-9]+:	67 89 04 25 11 22 33 ff 	mov[ ]+DWORD PTR ds:0xff332211,eax
 [ 	]*[a-f0-9]+:	67 89 04 65 11 22 33 ff 	mov[ ]+DWORD PTR \[eiz\*2\+0xff332211\],eax
 #pass
diff --git a/gas/testsuite/gas/i386/x86-64-addr32.d b/gas/testsuite/gas/i386/x86-64-addr32.d
index d9481a7439..c513f0dd8e 100644
--- a/gas/testsuite/gas/i386/x86-64-addr32.d
+++ b/gas/testsuite/gas/i386/x86-64-addr32.d
@@ -10,15 +10,15 @@  Disassembly of section .text:
 [ 	]*[a-f0-9]+:	67 48 8d 80 00 00 00 00[ 	]+lea[ 	]+0x0\(%eax\),%rax.*
 [ 	]*[a-f0-9]+:	67 49 8d 80 00 00 00 00[ 	]+lea[ 	]+0x0\(%r8d\),%rax.*
 [ 	]*[a-f0-9]+:	67 48 8d 05 00 00 00 00[ 	]+lea[ 	]+0x0\(%eip\),%rax.*
-[ 	]*[a-f0-9]+:	67 48 8d 04 25 00 00 00 00[ 	]+lea[ ]+0x0\(,%eiz,1\),%rax.*
+[ 	]*[a-f0-9]+:	67 48 8d 04 25 00 00 00 00[ 	]+lea[ ]+0x0,%rax.*
 [ 	]*[a-f0-9]+:	67 a0 98 08 60 00    	addr32 mov 0x600898,%al
 [ 	]*[a-f0-9]+:	67 66 a1 98 08 60 00 	addr32 mov 0x600898,%ax
 [ 	]*[a-f0-9]+:	67 a1 98 08 60 00    	addr32 mov 0x600898,%eax
 [ 	]*[a-f0-9]+:	67 48 a1 98 08 60 00 	addr32 mov 0x600898,%rax
 [ 	]*[a-f0-9]+:	67 48 a1 98 08 80 00 	addr32 mov 0x800898,%rax
-[ 	]*[a-f0-9]+:	67 48 8b 1c 25 98 08 80 00 	mov[ ]+0x800898\(,%eiz,1\),%rbx
+[ 	]*[a-f0-9]+:	67 48 8b 1c 25 98 08 80 00 	mov[ ]+0x800898,%rbx
 [ 	]*[a-f0-9]+:	67 48 a1 ef cd ab 89 	addr32 mov 0x89abcdef,%rax
-[ 	]*[a-f0-9]+:	67 48 8b 1c 25 ef cd ab 89 	mov[ ]+0x89abcdef\(,%eiz,1\),%rbx
+[ 	]*[a-f0-9]+:	67 48 8b 1c 25 ef cd ab 89 	mov[ ]+0x89abcdef,%rbx
 [ 	]*[a-f0-9]+:	67 48 b8 ef cd ab 89 00 00 00 00 	addr32 movabs \$0x89abcdef,%rax
 [ 	]*[a-f0-9]+:	67 48 bb ef cd ab 89 00 00 00 00 	addr32 movabs \$0x89abcdef,%rbx
 [ 	]*[a-f0-9]+:	67 a2 98 08 60 00    	addr32 mov %al,0x600898
@@ -26,9 +26,9 @@  Disassembly of section .text:
 [ 	]*[a-f0-9]+:	67 a3 98 08 60 00    	addr32 mov %eax,0x600898
 [ 	]*[a-f0-9]+:	67 48 a3 98 08 60 00 	addr32 mov %rax,0x600898
 [ 	]*[a-f0-9]+:	67 48 a3 98 08 80 00 	addr32 mov %rax,0x800898
-[ 	]*[a-f0-9]+:	67 48 89 1c 25 98 08 80 00 	mov[ ]+%rbx,0x800898\(,%eiz,1\)
+[ 	]*[a-f0-9]+:	67 48 89 1c 25 98 08 80 00 	mov[ ]+%rbx,0x800898
 [ 	]*[a-f0-9]+:	67 48 a3 ef cd ab 89 	addr32 mov %rax,0x89abcdef
-[ 	]*[a-f0-9]+:	67 48 89 1c 25 ef cd ab 89 	mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)
-[ 	]*[a-f0-9]+:	67 89 04 25 11 22 33 ff 	mov[ ]+%eax,0xff332211\(,%eiz,1\)
+[ 	]*[a-f0-9]+:	67 48 89 1c 25 ef cd ab 89 	mov[ ]+%rbx,0x89abcdef
+[ 	]*[a-f0-9]+:	67 89 04 25 11 22 33 ff 	mov[ ]+%eax,0xff332211
 [ 	]*[a-f0-9]+:	67 89 04 65 11 22 33 ff 	mov[ ]+%eax,0xff332211\(,%eiz,2\)
 #pass
diff --git a/opcodes/ChangeLog b/opcodes/ChangeLog
index e4e26a18d6..91d7f5b674 100644
--- a/opcodes/ChangeLog
+++ b/opcodes/ChangeLog
@@ -1,3 +1,9 @@ 
+2020-07-15  H.J. Lu  <hongjiu.lu@intel.com>
+
+	PR gas/26237
+	* i386-dis.c (OP_E_memory): Don't display eiz with no scale
+	without base nor index registers.
+
 2020-07-15  Jan Beulich  <jbeulich@suse.com>
 
 	* i386-dis.c (putop): Move 'V' and 'W' handling.
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index cd8a9a8d75..d1d7a7d94d 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -11818,7 +11818,7 @@  OP_E_memory (int bytemode, int sizeflag)
 		  /* Without base nor index registers, zero-extend the
 		     lower 32-bit displacement to 64 bits.  */
 		  disp = (unsigned int) disp;
-		  needindex = 1;
+		  needindex = scale;
 		}
 	      needaddr32 = 1;
 	    }
-- 
2.26.2