OSDev.org

I give up. Can't something else help me at the task of finding what exactly makes this kernel segfault ?
http://dl.free.fr/fCt2JuqFI/trunk.zip

What I found :
1/It's the access to vmem2 in init/kernel.cpp that makes things crash
2/That's because the vmem2 pointer holds an insane virtual address (0x0010da2000113000) instead of the awaited 0xb8000 value
3/Which happens because the initialisation of vmem2 at the top of kernel.cpp fails. Any further re-initialisation of vmem2 in kmain() makes things work.
4/The initialization fails because the load_kernel() function in arch/x86_64/bootstrap/lib/kernel_loader.c has not loaded the .data section of bin/kernel/kernel.bin properly. The .data section in bin/kernel/kernel.bin is fine, according to objdump, if it was loaded properly things wouldn't crash.
5/The data copying part of the load_kernel() function works fine, it's the source data which is to blame. However, the source address of the rw segment looks fine, too, at least compared to those of the rx and r segments. Plus it comes from the ELF64 header, so it shouldn't be messed up.
6/It therefore just looks like the kernel.bin file is not loaded properly. Which is highly unlikely because it is loaded by GRUB and GRUB does great (tm).

And here I'm stuck...

When I woke up this morning, I suddenly knew what I did not try. Experimented with making the stack 16 times larger. Problem solved. Sorry for the annoyance. I wish there was a hardware mechanism where you could manually specify the location of the top of the stack area and it would #GP when a stack overflow occurs...

Neoloander, there is a mechanism. Just allocate say n pages for the stack but leave the lowest page not-present (set P bit in pte to 0). If you touch that page you will get a page fault. This is a _very_ good idea.

Indeed. It won't work in the part where paging isn't already activated, but I should take care of this issue when filling in my page table. Thanks for reminding me of this !