Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
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
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
|
DetailsDescription:
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
Wednesday, 10 September 2014, 00:32 GMT
Reason for closing: Not a bug
Additional comments about closing: See comment
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.