GNU ld, inflating binary

Programming, for all ages and all languages.
Post Reply
User avatar
GraveMind
Posts: 12
Joined: Mon Feb 07, 2011 7:01 am
Location: London
Contact:

GNU ld, inflating binary

Post by GraveMind »

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
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: GNU ld, inflating binary

Post by bluemoon »

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.
User avatar
GraveMind
Posts: 12
Joined: Mon Feb 07, 2011 7:01 am
Location: London
Contact:

Re: GNU ld, inflating binary

Post by GraveMind »

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 $


User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: GNU ld, inflating binary

Post by bluemoon »

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.
User avatar
GraveMind
Posts: 12
Joined: Mon Feb 07, 2011 7:01 am
Location: London
Contact:

Re: GNU ld, inflating binary

Post by GraveMind »

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
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: GNU ld, inflating binary

Post by Solar »

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.
Post Reply