OSDev.org

Combuster wrote:It's called the BSS section. It's not vague, you only need to know how to use it to your advantage.

I don't know how undocumented parts can be used to my advantage... It's rather the source of additional work, because I have to carefully walk around them before they blow up into something totally new in the next release of the bootloader.
Then, it's my kernel developer's point of view. For the ones who develop a multiboot bootloader, to the contrary, the more undocumented the better, because it allows them to do what they want

Neolander wrote:

Combuster wrote:It's called the BSS section. It's not vague, you only need to know how to use it to your advantage.

I don't know how undocumented parts can be used to my advantage... It's rather the source of additional work, because I have to carefully walk around them before they blow up into something totally new in the next release of the bootloader.

Every ELF binary consists of .text, .data, and .bss. Nothing "undocumented" about it.

Combuster wrote:

Neolander wrote:

Combuster wrote:Multiboot doesn't specify where modules are loaded, only that you can dictate a single range (kernel image + x bytes) that should be left free for use. If you let your loader relocate, you might end up in module space.

Yet another magnificently vague part in the multiboot standard...

It's called the BSS section. It's not vague, you only need to know how to use it to your advantage.

Though making it over large makes testing with slow emulators like Bochs a real pain as you have to wait for it to be zero'd

Hmm... as far as I'm confused (jk) C++ relies on the C++ runtime library, which relies on the operating system. And as you're building the OS, it's up to you to be that runtime library, and therefore be the one executing the global constructors, providing basic C++ operation support, etc etc..

That's exactly what Neolander is trying to do. Check out the C++ Bare Bones - the compiler generates a .ctors section containing pointers to the constructors, but it's up to you to call them.

Globally, those Bare Bones articles are very nice for those of us who, after getting used to OS theory, want to see some code working before tweaking it

That's what they're there for. They give you confidence that your toolchain, emulator etc. are properly set up. Using them as a starting point, it also gives you a point of reference to determine at which point of the "tweaking" you introduced the problem.

Back when you wrote your first C program, you also started with a "hello" of some kind, and then worked from there. Working with kernel space code, there's pretty much that can go wrong even with a "hello", and that's where the BareBones come in: Minimum code to get it running, minimum assumptions on where you want to go from there.