Grub is complaining about executable file format

[Mel]

Hi,

I am using grub to boot my kernel, and it is working fine for now.

In the last few days, I am having problems with grub complaining about the executable file format, but I haven't changed how i compile my kernel ....

If i comment one line of code the kernel boots fine, but when I uncomment this line of code it doesn't ... it is just that weird ! Sources are avaiable if you are interested.

Did anyone had a problem like this or could give me any help ??

thanks in advance, samuelgoto

[zloba]

Heh, I had _exactly_ the same problem. I figured it's because the multiboot header is too far from the start and not being found.

Make sure your loader.asm (or wherever your multiboot header is) is linked first. That solved the problem for me.

[Pype.Clicker]

Just out of curiosity, how big is your kernel now ? it happens frequently that people miss one line in their linker script (usually about .rodata) and suddenly have a 1MB file with a large amount of zeroes between 4K and 1MB.

If the line you comment contains some constant string, then it may mean you're toggling whether there's some .rodata section or not...

Of course, if your loader.asm file is sent 1MB ahead from the file start, it will be harder to load by GRUB ...

[zloba]

Just out of curiosity, how big is your kernel now ?

mine was 20k-something when the problem appeared.

If the line you comment contains some constant string, then it may mean you're toggling whether there's some .rodata section or not...

I reproduced the problem on a dummy kernel with nothing but a bunch of loops, and no other files. "No strings attached". The size was similar.

[Pype.Clicker]

Just out of curiosity, how big is your kernel now ?

mine was 20k-something when the problem appeared.

I guess i should have made clearer the question was aimed at Mel

[Mel]

Well, thanks !!!! I am VERY happy someone had the same problem ( well, not happy for you having the problem, but for being able to help me .. well, u know what i mean .. hehhee ) !!!

I am currently at the university, and I don't have bochs installed here ( neither permission to install .. hehe ) so I can't really say that it works !!! But your answer sounds right ...

As soon as i get home i'll let you know if your solution works.

By the way,

1) yes, the function i am commenting ( wich gives me trouble ) does have a string ! I was acctually thinking about strings data problems too !!!
2) i don't have rowdata on my linker script ( to be honest, i don't know what rowdata is ... if you could give me a hint ... )
3) this is how i am linking my kernel ... $(OBJS) = screen.o gdt.o idt.o etc.o are many many .o object files compiled from C code ... start.o is where the multiboot header is, with the kernel entry point ...

ld $(LDFLAGS) -N -T link.ld -o unicampos.x $(OBJS) start.o switch.o critical.o

are you suggesting me to change this to

ld $(LDFLAGS) -N -T link.ld -o unicampos.x start.o $(OBJS) switch.o critical.o

so my entry point ( and multiboot header ) be at the begging ?

4) This is my ld script ... there is no rowdata ... what is this ? how should i use it ?

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



thanks in advance, i am very excited to get home and see if this works !!!

cya, mel

[zloba]

are you suggesting me to change this to

ld $(LDFLAGS) -N -T link.ld -o unicampos.x start.o $(OBJS) switch.o critical.o

Yes, exactly. According to the Multiboot spec:

The Multiboot header must be contained completely within the first 8192 bytes of the OS image, and must be longword (32-bit) aligned. In general, it should come as early as possible, and may be embedded in the beginning of the text segment after the real executable header.

So even if you don't have this problem now, if the code in $(OBJS) grows, you will eventually.

It looks like you may be missing the .rodata section too, as Pype said. I don't know much about linker scripts, I used the example linker.ld from BareBones.

[mel]

Yes !!!!

It works !! it is alive !! hahahha

There were acctually two problems occurring : grub complains about executable file type if multiboot header is too far from entry point and grub also complains if you don't have a rodata ( wich stands for read only data ) !!

Thank you very much !!! It has been of much help here !!!

cya, mel

[ZetItUp]

Well, thanks !!!! I am VERY happy someone had the same problem ( well, not happy for you having the problem, but for being able to help me .. well, u know what i mean .. hehhee ) !!!

I am currently at the university, and I don't have bochs installed here ( neither permission to install .. hehe ) so I can't really say that it works !!! But your answer sounds right ...

As soon as i get home i'll let you know if your solution works.

By the way,

1) yes, the function i am commenting ( wich gives me trouble ) does have a string ! I was acctually thinking about strings data problems too !!!
2) i don't have rowdata on my linker script ( to be honest, i don't know what rowdata is ... if you could give me a hint ... )
3) this is how i am linking my kernel ... $(OBJS) = screen.o gdt.o idt.o etc.o are many many .o object files compiled from C code ... start.o is where the multiboot header is, with the kernel entry point ...

ld $(LDFLAGS) -N -T link.ld -o unicampos.x $(OBJS) start.o switch.o critical.o

are you suggesting me to change this to

ld $(LDFLAGS) -N -T link.ld -o unicampos.x start.o $(OBJS) switch.o critical.o

so my entry point ( and multiboot header ) be at the begging ?

4) This is my ld script ... there is no rowdata ... what is this ? how should i use it ?

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



thanks in advance, i am very excited to get home and see if this works !!!

cya, mel

hello, i have the very same problem, could you paste your link.ld code here please? =)

[Solar]

Check zloba's answer, and his link into the Wiki, where you'll find the linker script you're looking for.

[ZetItUp]

aah, thanks =)
didnt see that one :/

EDIT: Wohoo, now it works =)
Thanks again!

[zloba]

I have a question about this missing section business:

it happens frequently that people miss one line in their linker script (usually about .rodata) and suddenly have a 1MB file with a large amount of zeroes between 4K and 1MB.

If the line you comment contains some constant string, then it may mean you're toggling whether there's some .rodata section or not...

So a section may be missing, but how and why does that result in 1Mb of zeroes? Wouldn't you just get "unresolved symbols" from linker for strings?

[AR]

The non-configured section (.rodata) ends up at 0x00000000 by default, when compiling to flat binary the linker is forced to insert all the 0s to fill the required space between 0 and 1MB.

[zloba]

the linker is forced to insert all the 0s to fill the required space between 0 and 1MB

why 1Mb? why not 4kb or 4Gb or 123456? what requires that?

edit: is it because the linker script put kernel at 0x100000=1Mb(dec)?

[Pype.Clicker]

exactly ;D