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