OSDev.org

To determine X.

When the osloader loads the kernel, it searches for the directory, inode or whatever for it's entry.
This holds the kernel size in bytes. Round up to the nearest sector boundary and and there is X - your kernel size!
Store safely and use as needed.
The size can then be divided by the sector size used on the disk to tell you how many sectors need to be loaded.

As mentioned in my previous message, the kernel size might not fall on a 4k boundary, so the size should be rounded up to the nearest 4k before using in a paged memory system.

If you're worried about wasted space, it shouldn't be too much and a little can be a good thing. Having data immmediatley after kernal code can cause caching 'freaks'. The processor thinks it's running self-modifried code and performance goes nasty downlike.

Pype.Clicker wrote: could it be possible that SIZEOF() doesn't take the ALIGN()ment into account ? the other possibility would be that headers/symbols/whatever are still hanging around (but that would surprise me, considering your "output_format("binary")" command.

Using an hex editor would be the best way to check ...

what about

Code: Select all

.text: {
     start_of_text = .;
     *(.text);
     *(.rodata);
     . = ALIGN(4096);
     end_of_text = . ;
}
text_size=end_of_text - start_of_text;

?

I was just thinking about that this morning. I'll see if it works and then get back to you with the results.

Update: The code you posted "pype" will not work if the "rodata" field is included in the .text section. It causes my print functions to not work, it doesnt like the end_of_text in there. If I add it to the end of the linker script, all goes well.

Here's what I found

I found out about the rodata section yesterday after some strange bugs. rodata stands for 'read only data' right? Is this the place where string constants like the format strings passed to printf are found?

If so, then it seems that the rodata is stored, by default, /after/ the text section, right at the end of the kernel. The reason I say this is because previously, I had not specified any rodata section in my linker script. I then started using the memory from __kernel_end_address (which was the address after the end of the .bss section). As a result, all my printf's stopped working! After I added entries for .rodata and .comments (whatever that is) in the linker script, the printf's started working fine again.

I figured out what I was doing wrong and am now getting 10KB for the total kernel_size. The size of the binary is 8KB.

What could be accounting for the 2KB? Could it be the binary format itself or is there some other explanation why its off?