Where does the first 0x1000 bytes comes from

[raywill]

To explain what's the problem,I have to paste some code:

Code: Select all

  
[section .text]   
[bits 16]
entry:
   cli
   mov word [0B0000h],9F44h
   mov word [0B0002h],9F46h

//////////////////////////////
the following is from the dumpobj
////////////////////////////// 
10000:   fa                      cli    
10001:   c7 06 00 00 44 9f       movl   $0x9f440000,(%esi)
10007:   c7 06 02 00 46 9f       movl   $0x9f460002,(%esi)
.......

but in UltraEdit/HexEdit I got the following bin code at the offset of 0x0000:1000,instead of 0x0000:0000 :

Code: Select all

FAC7 0600 0044 9FC7 0602 0046 9FC7 0604 
0040 9FC7 0606 0044 9FE8 0C00 E910 00B4

here is my command and link script.

Code: Select all

nasm kentry.asm -f coff -o kentry.o
ld -T ldscript kentry.o -o Kentry.bin
objdump --source Kentry.bin >krnl.lst

Code: Select all

ENTRY(entry)
SECTIONS{
   .text 0x10000 : {
      *(.text)
   }
   textEnd = . ;
   .data : {
      *(.data)
      *(.rodata)
   }
   dataEnd = .;
   .bss : {
      *(.common)
      *(.bss)
   }
   bssEnd = .;
}

Can anyone tell me why?
If I want to remove the first 0x1000 bytes ,what should I do?Or I should not remove it?
Thanks!

[Candy]

Can't see you indicating a binary format anywhere, so it's probably a COFF file. I expect them to be page aligned, so the first 0x1000 bytes are probably the header.

You should be able to figure out a solution now

[raywill]

You should be able to figure out a solution now

Do I need to use ELF as my object file format?But I don't know much about ELF.

If I use binary format,is it still OK to use .text .data .bss?

Still no solution....

[Candy]

You should be able to figure out a solution now

Do I need to use ELF as my object file format?But I don't know much about ELF.

If I use binary format,is it still OK to use .text .data .bss?

Still no solution....

Ok... a little more background:

Object files are compiled from source to a relocatable format (such as ELF, COFF, A.OUT and PE for example. There are more.). These relocatable objects are then linked to a single relocatable object (ld -r, or in the final linking step, in the memory of the linker). It then "finalizes" the link by fixing it up so it can be executed. At this time, it decides the format of the output and creates it accordingly.

You will want to use a relocatable format for the objects, you are already using one (I guess you're using COFF for that. That's ok.). You need to specify what needs to come out of the last link step in the linker file, and since you want a flat binary file (with no header), tell it to make a binary file. It will fix up all links, disallow shared libraries and so on.

[dushara]

An alternative solution is to use the MEMORY command in the linker script (this is what I did). Here's my linker script:

MEMORY
{
ram : ORIGIN = 0x00010000, LENGTH = 0xffffff
}

SECTIONS
{
.text : {
*(.text) ;
_etext = . ;
_data = . ;
*(.rodata*);
*(.data);
_edata = . ;
_bstart = . ;
*(.bss) *(COMMON) ;
_bend = . ;
} > ram
}

To convert to binary, I use objcopy (which you probably are aware of).