Hi, I've probably overlooked something simple because I can't imagine it's not possible.
For the bare metal runtime I'm writing for Go I implemented a memory allocator to bootstrap the language features. The idea is that the kernel written using the runtime will implement it's own memory manager which it can hook into the runtime so it'll use that instead.
I wrote this in my boot.s assembly to specify a section for this purpose:
Code:
.section .runtime_memory, "aw", @nobits
.set RUNTIME_MEMORY_SIZE, 67108864 # 64MB
.global runtime_memory_size
runtime_memory_size:
.long RUNTIME_MEMORY_SIZE
.global runtime_memory_top
runtime_memory_top:
.skip RUNTIME_MEMORY_SIZE
.global runtime_memory_bottom
runtime_memory_bottom:
The section in linker.ld is very straight forward:
Code:
/* Runtime memory for the allocator */
.runtime_memory BLOCK(4K) : ALIGN(4K)
{
*(.runtime_memory)
}
I picked an insanely large memory size for now until I get a better idea how much a kernel would generally require before being able to replace it. The fact that it's zero initialized annoys me because the compiler already zero's or initializes memory when it's requested from the runtime. So it's a pointless waste of time when loading the kernel.
As you can see I already define the section as @nobits, so it doesn't add anything to the ELF output. But judging from a memory dump it seems to initialize to zero no matter what I do.
I tried naming the section .noinit and the noload output section type. I also tried the .text section but it then just ignores @nobits and adds the bloat to the ELF output.
So I'm scratching my head and wondering what I'm doing wrong...
The reason I'm not using the _end symbol and using that as the start of a fixed size heap is that I thought it would be better if grub was aware of it's size so it can pick a proper place to put it at. But maybe I should rethink that or just accept that it's zero initialized?