https://sourceware.org/bugzilla/show_bug.cgi?id=29183
Bug ID: 29183
Summary: Inconsistent behaviors of Types with PTR operator
Product: binutils
Version: 2.38
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: j3r3miasmg at gmail dot com
Target Milestone: ---
Component: GAS
OS: Linux
The lack of PTR operator when any type is used generates a unexpected result.
Example code:
.global _start
.intel_syntax noprefix
_start:
mov al, [rdi]
mov eax, [rdi]
mov rax, [rdi]
mov al, BYTE [rdi]
mov eax, DWORD [rdi]
mov rax, QWORD [rdi]
mov al, BYTE PTR [rdi]
mov eax, DWORD PTR [rdi]
mov rax, QWORD PTR [rdi]
mov al, BYTE
mov eax, DWORD
mov rax, QWORD
Objdump output:
0000000000000000 <_start>:
0: 8a 07 mov al,BYTE PTR [rdi]
2: 8b 07 mov eax,DWORD PTR [rdi]
4: 48 8b 07 mov rax,QWORD PTR [rdi]
7: 8a 47 01 mov al,BYTE PTR [rdi+0x1]
a: 8b 47 04 mov eax,DWORD PTR [rdi+0x4]
d: 48 8b 47 08 mov rax,QWORD PTR [rdi+0x8]
11: 8a 07 mov al,BYTE PTR [rdi]
13: 8b 07 mov eax,DWORD PTR [rdi]
15: 48 8b 07 mov rax,QWORD PTR [rdi]
18: b0 01 mov al,0x1
1a: b8 04 00 00 00 mov eax,0x4
1f: 48 c7 c0 08 00 00 00 mov rax,0x8
Using `mov eax, DWORD [rdi]` as and example, it could be seen that when DWORD
is used but PTR is not, instruction result includes an offset of 4 bytes to the
source address, and the result in instruction 0xa of the objdump: `mov
eax,DWORD PTR [rdi+0x4]`. This behavior is different from instructions 0x2 and
0x13 of the obdjump when I believe it should not be.
This occurs because BYTE, WORD, DWORD and QWORD can be used as defines to 1, 2,
4 and 8 (check lines 0x18, 0x1a and 0x1f of objdump) and `mov eax, DWORD [rdi]`
is the same as `mov eax, 4[rdi]` and also equals to `mov eax, [rdi + 4]`.
Build Date & Hardware: binutils-2_38 Feb 9 - Ubuntu 20.04.4 LTS
--
You are receiving this mail because:
You are on the CC list for the bug.
