Left one works, right one doesn't.

Actually I found out what is going on.
When I comment out Call_Constructors(); GRUB doesn't report 16 KB any more.



Inside linker's data block:

Where did you get the idea of doing it like that? Is there a reason you're doing it like that?

At least the Wiki doesn't seem to suggest anything like that..?

Wiki's article on that subject seems to be very clogged and bloated.

Here is another even more clogged and bloated article. There are detailed sections on initialization in it. (It is actually true that the Wiki shows the _init implementation for the init_array ABI, without handling .ctors.)

May be someone will correct me on this, but your approach should work in principle. You are not handling exceptions and per-thread storage, but that is not relevant. Still, it should be at least something like this in the linker script:
Particularly, the ctors must be inside KEEP. Assuming that doesn't fix the issue, as always, you need to trace your code with gdb and track which ctors are called and what memory they write to.

Looks like one of your ctors simply overwrites Multiboot_Info memory.

Is that my fault anyhow?

Is that my fault anyhow?

I'm not convinced that C++ is a good language for beginners to use for OS development.

Im somehow convinced that C++ and OOP itself is not truly meant for any critical hardware close running code.
I mean, you can use it in userspace as much as you love, but imo the kernel should be written in a language where you can manage memory perfectly even though it can be annoying.
OOP is a waste of memory and speed even on fast processors.

I've nothing against OOP. My favourite OS was object oriented.

But I think C++ has too many pitfalls for beginners when it comes to low-level programming, linking with assembler routines, and the like. It's hard enough for some to realize that they can't use the C standard library when using C, let alone appreciating what they can and can't do with C++. I'm sure it's a fine language to use for someone who understands it fully.

When you manipulate different object types uniformly, you have polymorhism, C++ or not. Behavior variation requires data that specifies it, and the single pointer in C++ is pretty minimal cost. Error handling with branches, even if properly predicted by the CPU, should still be marginally slower in the normal path. It makes for a horribly looking coding style as well. Exceptions are slower in the failure path only, and it is rarely taken. Together with RAII, they make error handling much more capsulated affair. Templates offers type safe alternative to macros, and although it is true that sometimes compilers fail to chew them info efficient code, that depends on how extensively they are used and how deeply they are nested, as well as the compiler. Genericity is a very convenient library feature.

On the other hand, it is true that templates come at the cost of making the project header centric, and dependent on inclusion order. Also, polymorphism with some syntax features make the semantics so flexible, that the code looses its self-contained meaning and can become unpredictable. Exceptions introduce hidden control flow, which must be tracked at all times, and good knowledge of RAII becomes necessity. The biggest caveat in my opinion however is that people tend to produce high-level abstractions that eventually become costly. But this is not due to C++ in itself, but due to the comfort with which such abstractions are produced in OOP style. It is abstraction that is expensive, not C++.