GRUB: Error 13: Invalid or unsupported executable format

[McZ]

today I have got alot of "Error 13: Invalid or unsupported executable format" from GRUB when I have added a few lines to my kernel code just recently I added this timer_phase I found in a tutorial

Code: Select all

void timer_phase(int hz)
{
   int divisor = 1193180 / hz;       /* Calculate our divisor */
   outportb(0x43, 0x36);             /* Set our command byte 0x36 */
   outportb(0x40, divisor & 0xFF);   /* Set low byte of divisor */
   outportb(0x40, divisor >> 8);     /* Set high byte of divisor */
}

well that was no problem but then I added the line

Code: Select all

timer_phase(100);

into my kernel main and then GRUB said it was an invalid executable again, I have done a few minor changes to some functions here and there mostly extended my Error messages so they have a little bit more information but when I tried to create a nice "frame" around the message with stars (*) like this:

Code: Select all

******************
* Error message  *
******************

GRUB didn't like that I had a loop to fill out the spaces so the * after error message got at the end of the star line above so I removed that for loop and have no star at the end of the message and then it works.

But WHY does my kernel become invalid just by adding a little bit of code? My kernel compiles without any warnings.

[Solar]

Your Multiboot header is no longer in the first 8kB of code?

[Pype.Clicker]

you should find a couple of info about GRUB error messages in http://www.osdev.org/osfaq2/index.php/BareBones.

i'd be tempted to say that, in your case, either the multiboot header is pushed too far from the start of the file (i think it should be within the first 8KB or something alike), or that you introduce missing symbols that make your kernel non-executable (that can be the case if you do recursive linking).

[McZ]

will this make sure that the multiboot header allways get in the first 8kb? (assuming loader.o has the multiboot header)

Code: Select all

ld -o kernel.bin loader.o a.o b.o ...

or is there another way?

[Pype.Clicker]

the "mbchk" tool will tell you. You're also welcome to ask your linker to output a map of what it generated and check manually where the stuffs end up.

ld -o ... multiboot_header.o key.o mem.o vga.o etc. may or may not put the multiboot at start. For instance, if your linker script states ".text (*)" then ".data(*)" then at last ".rodata(*)" your multiboot_header will only ends up at the start if you placed it in .text section... if it's in .data, the code for any other module will precede it. If it's in .rodata (which will likely be the case if you define it in a C module), it's virtually the last thing...

In clicker, i have the multiboot sector in a dedicated .init section that is linked ahead of the rest so that i'm sure whatever C could do won't mess with it.

[McZ]

my multiboot header is decleared in the loader.asm which is called from grub. How can I check which section the multboot header is in?

[DruG5t0r3]

I haven't posted in this forum in months...oh well There I am.

This has happened to me before where IF I added one single line of code to my kernel it would run into that error. I found that the only thing that fixed it is that at that time I was compiling my kernel in binary mode rather than in elf format. Linking it in elf format fixed my problem.

[Pype.Clicker]

my multiboot header is decleared in the loader.asm which is called from grub. How can I check which section the multboot header is in?

rtfm.

<man ld>
-Map mapfile
Print a link map to the file mapfile. See the
description of the -M option, above.

that should show you were things are, e.g.

Code: Select all

Memory Configuration

Name             Origin             Length             Attributes
*default*        0x0000000000000000 0xffffffffffffffff

Linker script and memory map

                0x0000000000100000                . = 0x100000
                0x0000000000100000                __start_image = .
                0x0000000000100000                __start_init = .

.init           0x0000000000100000     0x1628
 *.o(kickdata)
 kickdata       0x0000000000100000       0xb0 lowlevel.o
                0x0000000000100030                datarl
                0x0000000000100008                codeos
                0x0000000000100010                dataos
                0x0000000000100018                zeroos
...

with a binary file, the slightest mistake in section placement may result in gaps in the file (e.g. large areas of zeroes)...