Bug in decoding of x86 index operations in Intel mode?

gdb+steven.murdoch@cl.cam.ac.uk gdb+steven.murdoch@cl.cam.ac.uk
Mon Jul 12 16:29:00 GMT 2004


I have encountered some strange behaviour in the disassembly of some
instructions in Intel format, but would like to check before reporting
a bug.

For testing purposes I assembled the following program

---
$ cat objdump_test.S
	mov %eax,0x8(%esp)
	mov %eax,0x8(%esp,%esi,1)
	mov %eax,0x8(%esp,%esi,2)
	mov %eax,0x8(%esp,%esi,4)

$ as -o objdump_test.o objdump_test.S 
---

Then disassembled it to AT&T syntax

---
$ objdump --disassemble objdump_test.o
[...]
00000000 <.text>:
   0:   89 44 24 08             mov    %eax,0x8(%esp,1)
   4:   89 44 34 08             mov    %eax,0x8(%esp,%esi,1)
   8:   89 44 74 08             mov    %eax,0x8(%esp,%esi,2)
   c:   89 44 b4 08             mov    %eax,0x8(%esp,%esi,4)
---

Which was what I put in.

However if I disassembled it to Intel syntax, the scale factor gets
lost.

---
$ objdump --disassemble objdump_test.o -Mintel
[...]
00000000 <.text>:
   0:   89 44 24 08             mov    DWORD PTR [esp+8],eax
   4:   89 44 34 08             mov    DWORD PTR [esp+esi+8],eax
   8:   89 44 74 08             mov    DWORD PTR [esp+esi+8],eax
   c:   89 44 b4 08             mov    DWORD PTR [esp+esi+8],eax
---

If I disassemble it in IDA, the scale factor is retained.

---
.text:08000000		       mov     [esp+8],	eax
.text:08000004		       mov     [esp+esi+8], eax
.text:08000008		       mov     [esp+esi*2+8], eax
.text:0800000C		       mov     [esp+esi*4+8], eax
---

Is this a known bug? I can't find it on bugzilla, so if it is
considered a bug I will report it.

Thank you,
Steven Murdoch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20040712/13632d19/attachment.sig>


More information about the Binutils mailing list