'Unsupported executable format' when doing loops

[CookiE]

Hi,

Sorry for the title I wasn't sure what to put there. So here the case, I've just started looking at some kernel development this weekend and allready I am tearing my hair out. I've been following the Bran's Kernel Development tutorial but I ran into problems with my strlen function. I implemented it like this:

Code: Select all

unsigned int strlen(const char *str)
{
    unsigned int len;
    for(len = 0; *str != '\0'; str++, len++);
    return len;
}

But whenever i called it in my main function the kernel whould not load in grub. (I got error 17 unsupported executable format). After playing around abit I was not able to figure out what caused this. But I did find something strange. The first code below runs fine, but when i change i < 2 to anything higher like i < 3 i get the same error 17 when loading my kernel.

Code: Select all

unsigned char* textmem = (unsigned char *) 0x0B8000;
char *str = "Hello world";
int i;
// Prints He, but if i change the condition to i > 3 or str[i] != '\0' for that matter
// grub whon't load my kernel image
for(i = 0; i < 2; i++) {
    textmem[2*i] = str[i];
    textmem[2*i+1] = str[i];
}

I guess both of those problems are related but i really have no idea what may be causing them. If anyone has any clues as to what may help me please drop a comment.

P.S
I compile my code using the following commands (start.asm simply calls my kmain() function):

Code: Select all

nasm -f aout -o start.o start.asm
gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin -I./include -c -o main.o main.c
ld -T link.ld -o kernel.bin start.o (Using the linker script at http://www.osdever.net/bkerndev/Docs/basickernel.htm)

Runar

[pcmattman]

The multiboot header must be in the first 8 KB of the loaded binary, or else it won't recognize the format.

Try putting start.o first on the linker line rather than second.

[CookiE]

Thanks for you response, I had a look at the compiled kernel.bin, once when i > 2 and once when i > 3. Whats strage is that the size the first time is 4096 bytes, the second time its nothing less that 1052660 bytes. Doing a hexdump shows the that file start with a string I defined in my c source, then lots of empty space before the boot header. I really can't understand why that whould be happening. Can it be a bug in the linker script? This is atleast what i have in link.ld

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
phys = 0x00100000;
SECTIONS
{
  .text phys : AT(phys) {
    code = .;
    *(.text)
    *(.rodata)
    . = ALIGN(4096);
  }
  .data : AT(phys + (data - code))
  {
    data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss : AT(phys + (bss - code))
  {
    bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .;
}

Which again is the same as listed in the tutorial i linked to in my previous post.

Any help whould be appreciated.


Edit: I was searching around on the net for a solution and somewhere I saw someone using elf32-i386 output format insted of binary as I had in my linker file. This seems to solve the problem, I'll have to do some more research before I'll understand why but for now I'm just happy to be able to print to the screen again

[pcmattman]

I still suggest putting start.o first on the linker script. ELF rather than plain binary is also a requirement for GRUB unless you want to use the AOUT kludge.

[CookiE]

I've got start.o at the start of the linker line, it looks something like this:
ld -T link.ld -o $(KERNELBIN) $(AS_OBJS) $(C_OBJS)
where start.o is the only assembly object.

[Owen]

Code: Select all

nasm -f aout -o start.o start.asm

Try -f elf instead.