Programming, for all ages and all languages.
GraveMind
Posts: 12 Joined: Mon Feb 07, 2011 7:01 am
Location: London
Contact:
Post
by GraveMind » Wed Mar 14, 2012 1:31 pm
Hi,
I have a problem and searching has gotten me nowhere this afternoon. Basically my 16 bit code is being assembled and linked fine to the constraints of 512bytes (for a bootloader). However as soon as I add an instruction the file is inflated with zero bytes.
This code is fine and stays 512bytes in size:
Code: Select all
.code16
.text
.global _start
_start:
/*
* Starting code for bootloader
* IN:
* OUT:
* DESCRIPTION:
*/
.bootloader_begin:
/*
* DATA USED BY PROGRAM
*
*/
.data
#STRINGS
kernel_filename: .ascii "KERNEL BIN"
disk_error: .asciz "Floppy disk error..."
file_not_found: .asciz "KERNEL.BIN not found"
reboot_message: .asciz "Press any key to reboot..."
#PADDING
.org (510 - ($$ - $)),0x00
#MAGIC NUMBER FOR BOOT
.byte 0x55, 0xAA
.buffer:
This code does not and I have only added a single instruction
Code: Select all
.code16
.text
.global _start
_start:
/*
* Starting code for bootloader
* IN:
* OUT:
* DESCRIPTION:
*/
.bootloader_begin:
movw 0x07C0, %ax
/*
* DATA USED BY PROGRAM
*
*/
.data
#STRINGS
kernel_filename: .ascii "KERNEL BIN"
disk_error: .asciz "Floppy disk error..."
file_not_found: .asciz "KERNEL.BIN not found"
reboot_message: .asciz "Press any key to reboot..."
#PADDING
.org (510 - ($$ - $)),0x00
#MAGIC NUMBER FOR BOOT
.byte 0x55, 0xAA
.buffer:
Am assembling with "as file -o file.o" and linking with "ld --oformat binary --Ttext 0x7c00 -o boot.bin boot.o"
Any ideas?
Thanks,
Jim
bluemoon
Member
Posts: 1761 Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong
Post
by bluemoon » Wed Mar 14, 2012 1:47 pm
GraveMind wrote: linking with "ld --oformat binary --Ttext 0x7c00 -o boot.bin boot.o"
Your
host version ld may default to split .text and .data into aligned block.
GraveMind
Posts: 12 Joined: Mon Feb 07, 2011 7:01 am
Location: London
Contact:
Post
by GraveMind » Wed Mar 14, 2012 2:37 pm
bluemoon wrote: GraveMind wrote: linking with "ld --oformat binary --Ttext 0x7c00 -o boot.bin boot.o"
Your
host version ld may default to split .text and .data into aligned block.
On looking at the object format it's spitting out host 64 bit code, I thought the ".code16" might have stopped that, does this mean I have to build a cross compiler to target 16bit?
Code: Select all
boot.o: file format elf64-x86-64
boot.o
architecture: i386:x86-64, flags 0x00000010:
HAS_SYMS
start address 0x0000000000000000
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000003 0000000000000000 0000000000000000 00000040 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000200 0000000000000000 0000000000000000 00000044 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 0000000000000000 0000000000000000 00000244 2**2
ALLOC
SYMBOL TABLE:
0000000000000000 l d .text 0000000000000000 .text
0000000000000000 l d .data 0000000000000000 .data
0000000000000000 l d .bss 0000000000000000 .bss
0000000000000000 l .text 0000000000000000 .bootloader_begin
0000000000000003 l .text 0000000000000000 .no_change
0000000000000003 l .text 0000000000000000 .floppy_ok
0000000000000003 l .text 0000000000000000 .read_root_dir
0000000000000003 l .text 0000000000000000 .search_dir
0000000000000003 l .text 0000000000000000 .next_root_entry
0000000000000003 l .text 0000000000000000 .found_file_to_load
0000000000000003 l .text 0000000000000000 .read_fat
0000000000000003 l .text 0000000000000000 .fatal_disk_error
0000000000000003 l .text 0000000000000000 .read_fat_ok
0000000000000003 l .text 0000000000000000 .load_file_selector
0000000000000003 l .text 0000000000000000 .calc_next_cluster
0000000000000003 l .text 0000000000000000 .odd
0000000000000003 l .text 0000000000000000 .even
0000000000000003 l .text 0000000000000000 .next_cluster_cont
0000000000000003 l .text 0000000000000000 .end
0000000000000003 l .text 0000000000000000 .reboot
0000000000000003 l .text 0000000000000000 .print_string
0000000000000003 l .text 0000000000000000 .reset_floppy
0000000000000003 l .text 0000000000000000 .logSec2hts
0000000000000000 l .data 0000000000000000 kernel_filename
000000000000000b l .data 0000000000000000 disk_error
0000000000000020 l .data 0000000000000000 file_not_found
0000000000000035 l .data 0000000000000000 reboot_message
0000000000000200 l .data 0000000000000000 .buffer
0000000000000000 g .text 0000000000000000 _start
0000000000000000 *UND* 0000000000000000 $$
0000000000000000 *UND* 0000000000000000 $
bluemoon
Member
Posts: 1761 Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong
Post
by bluemoon » Wed Mar 14, 2012 2:44 pm
IIRC, gcc version > 4.2.0 dropped support for 16-bit output.
However, for boot record you don't need a linker, I'm not sure on as but if you use nasm you can ask for -f bin directly.
GraveMind
Posts: 12 Joined: Mon Feb 07, 2011 7:01 am
Location: London
Contact:
Post
by GraveMind » Wed Mar 14, 2012 2:57 pm
bluemoon wrote: IIRC, gcc version > 4.2.0 dropped support for 16-bit output.
However, for boot record you don't need a linker, I'm not sure on as but if you use nasm you can ask for -f bin directly.
Oh I see, I did wonder why most people were not using gcc for building bootloaders... I just wanted to see without a lot of extra work was it possible. Guess I will stick to nasm/fasm for my bootloader
Cheers,
Jim
Solar
Member
Posts: 7615 Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:
Post
by Solar » Thu Mar 15, 2012 2:43 am
bluemoon wrote: IIRC, gcc version > 4.2.0 dropped support for 16-bit output.
I don't see where GCC plays into this. This is binutils only, and apparently binutils 2.22
still documents the feature .
Every good solution is obvious once you've found it.