FS#41708 - [binutils] as works improper on mov instruction involving label address operand

Attached to Project: Arch Linux
Opened by Tan Si Nan (tansinan_1995) - Wednesday, 27 August 2014, 03:32 GMT
Last edited by Allan McRae (Allan) - Wednesday, 10 September 2014, 00:32 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

when one of the operand of the mov instruction is an memory address of an label, the as command
actually interpret it as $0x0. while the same file is assembled correctly on Ubuntu and MinGW(Windows)

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:

create a file test.s

/* test.s */
.code16

mov $0x07C0, %ax /* Set up 4K stack space after this bootloader*/
add $288, %ax /* (4096 + 512) / 16 bytes per paragraph*/
mov %ax, %ss
mov $4096, %sp
mov $0x07C0, %ax /* Set data segment to where we're loaded*/
mov %ax, %ds


/* I also tried mov $LC0, %si */
mov LC0, %si
call print_string

jmp .

print_string:
mov $0x0e, %ah
_loop:
lodsb
cmp $0, %al
je _done
int $0x10
jmp _loop
_done:
ret

LC0:
.ascii "Hello world"
.byte 0
.byte 0

execute:

as test.s -o print

and then execute

objdump print.o -d -m i8086

The result is:

Disassembly of section .text:

0000000000000000 <print_string-0x18>:
0: b8 c0 07 mov $0x7c0,%ax
3: 05 20 01 add $0x120,%ax
6: 8e d0 mov %ax,%ss
8: bc 00 10 mov $0x1000,%sp
b: b8 c0 07 mov $0x7c0,%ax
e: 8e d8 mov %ax,%ds
10: be 00 00 mov $0x0,%si
13: e8 02 00 call 18 <print_string>
16: eb fe jmp 16 <print_string-0x2>

0000000000000018 <print_string>:
18: b4 0e mov $0xe,%ah

000000000000001a <_loop>:
1a: ac lods %ds:(%si),%al
1b: 3c 00 cmp $0x0,%al
1d: 74 04 je 23 <_done>
1f: cd 10 int $0x10
21: eb f7 jmp 1a <_loop>

0000000000000023 <_done>:
23: c3 ret

0000000000000024 <LC0>:
24: 48 dec %ax
25: 65 gs
26: 6c insb (%dx),%es:(%di)
27: 6c insb (%dx),%es:(%di)
28: 6f outsw %ds:(%si),(%dx)
29: 20 77 6f and %dh,0x6f(%bx)
2c: 72 6c jb 9a <LC0+0x76>
2e: 64 00 00 add %al,%fs:(%bx,%si)

Note 10: be 00 00 mov $0x0,%si
in which LC0 is replace by $0x0, while LC0 is not at the address 0x0


This task depends upon

Closed by  Allan McRae (Allan)
Wednesday, 10 September 2014, 00:32 GMT
Reason for closing:  Not a bug
Additional comments about closing:  See comment
Comment by Allan McRae (Allan) - Sunday, 07 September 2014, 09:32 GMT
What version of binutils do you have in Ubuntu and MinGW?
Comment by Tan Si Nan (tansinan_1995) - Sunday, 07 September 2014, 14:27 GMT
MINGW: as -v
GNU assembler version 2.24 (i686-w64-mingw32) using BFD version (GNU Binutils) 2.24

I tried Ubuntu on my classmate's PC, so I don't exactly know the version, but it should be the latest stable one.......

I really worry that I need to apologize for this may be not a bug... I'm actually taking a course on assembly language, so I tried some boot-sector programming and got this problem.

But later the teacher mentioned that the as generates object file, in which some address are uncertain until linking, thus it is possible that some address is filled with zero
May be that's why they are not the offset relative to the beginning of the file

So if I'm wrong... just close the bug, I'm so sorry. Anyway, I really curious about what makes the difference.
Comment by Allan McRae (Allan) - Wednesday, 10 September 2014, 00:32 GMT
I'm closing this as it appears not a bug. Reopen if you have more detail confirming it is.

Loading...