Linking - from 20k to 1Mb

[Endar]

You guys have seen that movie where the guy in the cubicle bashes his computer with his keyboard??

I am almost there. (I probably would be if I had a few spare keyboards lying around)

For the moment, we'll ignore the fact (which I am still working on) that my OS won't print to the screen, except for the first time, where it fills the screen with spaces (clears it).

Right now, we'll concentrate on the fact that somehow, by compiling and linking my kernel with 2 extra files, both of which are under 100 lines, my kernel can jump in size from 20kb to 1 megabyte.

I think this is also directly related to my other problem, that when I try and run this kernel, grub tells me that it is an "Invalid or unsupported executable format".

Has this ever happened to people? Frankly, it just doens't make sense to me.

[nick8325]

It could be that your kernel is being linked with a start address of 1MB, but a section of it is being placed at 0MB by the linker instead.

Try linking it to ELF first (or PE, if you're on Windows). Then run objdump -h on the file and see what load addresses each of the sections has.

If one of them has been given a load address of 0 by mistake, you'll need to put it in your linker script (if it's .ctors, you'll need to get your kernel to run constructors as well. I think that's in the OS-FAQ).

[Phugoid]

May we see your linker script or command line, as well as the rest of the commands you build width?

[Candy]

My guess is that .rodata is put at 0 while the rest is at 0x100000 in a pure binary file.

Solution would be to objdump the source objects to see whether you have all the sections and to link to a non-binary format.

[DruG5t0r3]

I've had that same problem before, where at some point when I coded...if i've added one single more line of code...the size of the kernel would jump from a few bytes to a few megs...keyboard head bangin' indead...reason I found is that you should never link the kernel in binary mode but in elf mode.

OUTPUT_FORMAT("elf32-i386","elf32-i386","elf32-i386");

Also make sure that the multiboot section for grub is within the first 8192 bytes of the kernel.

[Endar]

Okay, I've changed the link script to link in elf format, and I've objdump'd it and everything seems to be there and in order.

The size has gone down from over 1 meg to its usual much smaller size (now 17kb).

So, was linking in elf format just for checking? Or should grub be able to run a kernel in elf format? I tried and it said "Multiboot-elf <hex number>" "Error 28: Selected item cannot fit into memory"

Where am I at now?

[AR]

If you're in Bochs you may want to check your Megs settings, are you sure the objdump reported everything starting at 0x10000?

[Endar]

The megs settings are at 32, and when I do "objdump -h" on the kernel, that gives me info on the headers, part of which I don't understand (VMA, LMA ???), but when I do "objdump -D" on the kernel, I the first address of the first thing shown is 0x100000.

Is that right? Its the same number as in my linking script, so it seems to be right.

[AR]

VMA is the virtual address, LMA is the physical address.

[Endar]

If I do "objdump -h" on the kernel, I get that most of the physical addresses are at least 0x100000.

For two things, I get an LMA of 0 (.note.GNU-stack and .comment), and for .rodata.str1.4 the LMA address is 0xf8.

[AR]

The .rodata thing is most likely your problem.

In your linkscript add *(.rodata*) to the .text section.

[Endar]

YES!!!

Thanks AR, it did indeed work!!

And, in some sort of double whammy, the problem that I spoke of in my first post in this thread, where the OS won't print to the screen, this has also been solved!!!

AR, I appreciate your quality help, as I do all the people that replied to this thread. Thanks.

[AR]

Ah, I can explain the reason for that. The .rodata sections means "ReadOnly Data", GCC uses it to store constants from all your const variables as well as strings, the reason you weren't getting any output was probably because the strings weren't in memory where it thought they should be.