OSDev.org

Hi! All this tutorials and forum posts have helped me a lot! I have just started my own "OS", and I am planning on keeping the memory management very simple. No multitasking, no applications, no paging, just the kernel in ring 0. I can set the VGA with the bios, draw on screen with flipping, well anyway,
my question is about the size of my kernel. I have found a couple of posts about it already, and I just wanted to have some more info about it.
I put a symbol end in my linker-script, after the code and data, and before bss, and I tried the following:
- extern int end; // C
printf("bla %d", &end - 0x100000); // wrong size, size is +- 350000 decimal, is too big, (i dont know if that 1MB in hex is 1MB, but I just put a couple of zero's in there for this post, in my code it's the correct size anyway)

- as a parameter in main(void * end) pushed from asm
push end ; .asm
printf("bla %d", end); // same as above

My linker script uses the aout format ("binary"). My kernel starts at 1MB.
From what I understand the size end - 1MB should be 8192, (2x 4096 for .text and data)? correct me if I am wrong.


Further more I have another question about the size of my kernel.
I have put a global char LARGE_BUFFER[FFFFFF] in a C file, and I guess that goes into the bss section, because it's uninitialized data. In that file I do a memset on all those bytes, and all is fine. When I set the bios in VMware to include the memory gap at 15MB, grub correctly complains about the size of my kernel.
What I dont understand is where the linker-script fits in all this. In there the bss is 8192 bytes, so how can I put such a large buffer in there. Furthermore why do I have to set a bss section in my assembly code as well? And what is the relationship with that and the likerscript?

Is it correct for me to assume that the code should not get bigger than 4096 because it will overlap the data, and should data not get bigger than 4096 because it overlaps bss, and to assume that it doesnt matter how big bss is, because it wont overlap anything?

Thanks for your time reading this, sry for the bad english, and thanks in advance for comments/answers!

Matthijs Dinant

matthijs wrote:I put a symbol end in my linker-script, after the code and data, and before bss, and I tried the following:
- extern int end; // C
printf("bla %d", &end - 0x100000); // wrong size, size is +- 350000 decimal, is too big, (i dont know if that 1MB in hex is 1MB, but I just put a couple of zero's in there for this post, in my code it's the correct size anyway)

A couple of points: GCC, at least, accepts "extern void end", which is a good way of stopping you accidentally trying to use the value, rather than the address, of the symbol.
Secondly, you can avoid the problem with not knowing the offset by including a 'start' symbol as well and subtracting the addresses appropriately.

matthijs wrote:From what I understand the size end - 1MB should be 8192, (2x 4096 for .text and data)? correct me if I am wrong.

Each section should simply be a multiple of 4K, but for a small kernel each section is likely to be 4K.

matthijs wrote:Furthermore why do I have to set a bss section in my assembly code as well? And what is the relationship with that and the likerscript?

Setting the bss section tells the assembler to put the data (which must, of course, be uninitialised) into the bss section. It's that simple.

matthijs wrote:Is it correct for me to assume that the code should not get bigger than 4096 because it will overlap the data, and should data not get bigger than 4096 because it overlaps bss, and to assume that it doesnt matter how big bss is, because it wont overlap anything?

Nope, the sections just expand - if the text segment grows above 4K, the data segment will just move up by the appropriate number of pages.

matthijs wrote:sry for the bad english

To be honest, I didn't notice anything, other than the occasional misspellings that anyone's going to make. Same goes for most cases where people have said something like that.

That was very helpful. Just 2 more things. If the code and data segments grow automatically when my source gets bigger, then why does one have to specify a size in the first place? And why is a multiple of 4096 important? Is that because of the default size of a page perhaps?
Secondly I assume now that there is only one .bss section in a linked file, the one specified by the linkerscript. When I set a .bss in a .asm file, it refers to the one declared in the linker-script, and has that inititial size no matter what I set in the .asm?

Thanks again, Matthijs

4kb is the only* size supported by paging on x86 CPUs. When you set up paging, you'll probably want to mark your code read only for security reasons. You aren't setting the size of the sections; you're setting the alignment.

(* Only you're likely to see inside an executable anyway - some places may use 4MB, or more rarely, 1GB paging)

Owen wrote:When you set up paging, you'll probably want to mark your code read only for security reasons.

Ah, but then what about implementing something like ksplice? (a program which allows patching the Linux kernel while it is running)
But seriously, read-only kernel code does help with security, but function pointers (which are heavily used for some of the more useful types of abstraction) are still entirely mutable...

Owen wrote:(* Only you're likely to see inside an executable anyway - some places may use 4MB, or more rarely, 1GB paging)

Somehow you skipped over 2MB, which was introduced in the middle (and is more likely than 4MB for new processors/OSes because only 32-bit non-PAE paging allows those)
Anyway, generally only 4K pages are used in executables and the kernel can use larger pages when it decides it's appropriate.

One notable advantage of using different page sizes: most processors have separate TLBs for different page sizes, so (for example) placing the most-often-used parts of the kernel (think interrupt handlers) in large pages and everything else in small ones can provide a small speed boost (but I imagine that in many cases cache pollution will be the limiting factor for interrupt latency)

Woops! I don't know how I mentioned the PAE 1GB pages but not 2MB, and then threw 4MB into the mix

I think my brain needs adjustment.