Bug 4430 - We aren't consistent on displacement in x86 disassembler
Summary: We aren't consistent on displacement in x86 disassembler
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-26 15:00 UTC by H.J. Lu
Modified: 2007-04-27 04:24 UTC (History)
1 user (show)

See Also:
Host:
Target: i686-pc-linux-gnu
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2007-04-26 15:00:09 UTC
We aren't consistent in the format we use on displacement:

----
static void
print_operand_value (char *buf, int hex, bfd_vma disp)
...
static void
OP_E (int bytemode, int sizeflag)
{
...
	    print_operand_value (scratchbuf, !riprel, disp);
...
	      print_operand_value (scratchbuf, modrm.mod != 1, disp);
...
	      print_operand_value (scratchbuf, 1, disp);
...
	    print_operand_value (scratchbuf, 0, disp);
...
	      print_operand_value (scratchbuf, modrm.mod != 1, disp);
...
	  print_operand_value (scratchbuf, 1, disp & 0xffff);
}
----

That is we use hex or decimal for displacement, depending on Intel
mode, RIP relative, modrm.mod != 1 and 16bit address mode. It is
confusing.
Comment 1 H.J. Lu 2007-04-26 15:50:15 UTC
I guess that the intend was for 8bit displacement, we use decimal and
for 16/32bit displacement, we use hex. But we didn't do it correctly:

bash-3.1$ cat y.s
        mov 12(%rip), %eax
        mov 12(%r12), %eax
bash-3.1$ gcc -c y.s
bash-3.1$ objdump -d y.o

y.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <.text>:
   0:   8b 05 0c 00 00 00       mov    12(%rip),%eax        # 0x12
   6:   41 8b 44 24 0c          mov    0xc(%r12),%eax

We can do one of

1. Use decimal on all 8bit displacements and hex on all 16/32bit
displacement.
2. Use hex on all displacements.
Comment 2 H.J. Lu 2007-04-27 05:24:09 UTC
Fixed by

http://sourceware.org/ml/binutils/2007-04/msg00353.html