OSDev.org

Posted: **Wed Jun 11, 2008 4:57 am**

I'm currently using this script:

OUTPUT_FORMAT("elf32-i386")
ENTRY(kstart)
SECTIONS
{
  .text  0x100000 :
  {
    text = .; _text = .; __text = .;
    *(.text)
    . = ALIGN(4096);
  }
  .data  :
  {
    data = .; _data = .; __data = .;
    *(.data)
    kimage_text = .;
    LONG(text);
    kimage_data = .;
    LONG(data);
    kimage_bss = .;
    LONG(bss);
    kimage_end = .;
    LONG(end);
    . = ALIGN(4096);
  }
  .bss  :
  {
    bss = .; _bss = .; __bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .; _end = .; __end = .;
}

with this command to link my object files:

Code: Select all

i386-linux-ld -T linker.ld -o fpcos obj\*.o

And it used to work fine until last night. I changed some file contents and ld starts linking them in the wrong way. I always got "error 13: invalid or unsupported executable format", because the entry point in the script is placed by ld in the middle of the executable (from my quick analyze, it links them alphabetically), making it impossible for GRUB to load. So, I change the command to link them where my loader and kernel are the first two and it works! Can someone explain how can this happen? I thought ld was smart enough to put entry point in the correct place (which I think, the first line in .text segment).

Posted: **Wed Jun 11, 2008 5:12 am**

This is because of the grub multiboot header being out of the range searched. Try renaming the start.asm or similar to 0start.asm or specifically state it so it is linked first.

The files are sorted alphabetically because of the obj\*.o sorting them.

Posted: **Wed Jun 11, 2008 5:32 am**

But previously it works perfect. Does it have anything to do with file access time?

Posted: **Wed Jun 11, 2008 6:23 am**

no it is because the header has been moved by an increased file before the entrypoint file, this means that grub cannot find the information required to boot your kernel.

Using the old version of my os as an example:
kernel.bin file order:

gdt.c
kb.c
main.c
scrn.c
start.asm
...

When the files before start.asm grew to large the multiboot header was shifted out of the range that grub looks in.

OSDev.org

ld weird behavior

ld weird behavior