OSDev.org

Hello.
To my understanding uninitialized global variables are "stored" in the BSS, as entries without values.
Obviously the things in the BSS will get allocated on RAM during runtime, just like DATA and RODATA.

My question is: does the memory map provided by GRUB show the RAM associated with the segments as "Available" or "Reserved"?

Thanks.

I don't believe that the memory map shows your kernel at all. (Could be wrong there).

At any rate it should be easy enough to test. Simply dump the memory map to screen, and compare the regions with those in your symbol table. Don't know where the .bss ends? Simply add a symbol at the end called .end or something (which is what my kernel looks for anyway).

The memory map does not reflect this. In case of GRUB it is a straight dump of bios e820h memory map.

You should iterate the multuboot modules list and subtract that memory from the memory map yourself.

dozniak wrote:You should iterate the multuboot modules list and subtract that memory from the memory map yourself.

My kernel is a single executable. Please elaborate what the module list represents in this case, because I'm a bit confused.

For reference, the paragraph about modules in the Multiboot specification seems to not apply for my kernel:
http://www.gnu.org/software/grub/manual ... ot-modules

Multiboot specification wrote:Many modern operating system kernels, such as Mach and the microkernel in VSTa, do not by themselves contain enough mechanism to get the system fully operational: they require the presence of additional software modules at boot time in order to access devices, mount file systems, etc.

Just define linker symbols start and end and use them in this case to amend the memory map.

dozniak wrote:Just define linker symbols start and end and use them in this case to amend the memory map.

Thank you.

To complete this thread I'll post links to the relevant Wiki pages:
http://wiki.osdev.org/Linker_Scripts
http://wiki.osdev.org/Using_Linker_Script_Values