When compiled with gcc 4.6.1, 32-bit Sortix would triple fault during
early boot: When the TLB is being flushed, somehow a garbage value had
sneaked into Sortix::Memory::currentdir, and a non-page aligned (and
garbage) page directory is loaded. (Triple fault, here we come!)
However, adding a volatile addr_t foo after the currentdir variable
actually caused the system to boot correctly - the garbage was written
into that variable instead. To debug the problem, I set the foo value
to 0: as long as !foo (hence the name nofoo) everything was alright.
After closer examination I found that the initrd open code wrote to a
pointer supplied by kernel.cpp. The element pointed to was on the
stack. Worse, its address was the same as currentdir (now foo).
Indeed, the stack had gone into the kernel's data segment!
Turns out that this gcc configuration stores variables in the data
segment in the reverse order they are defined in, whereas previous
compilers did the opposite. The hack used to set up the stack during
early boot relied on this (now obviously incorrect) fact.
In effect, the stack was initialized to the end of the stack, not
the start of it: completely ignoring all the nice stack space
allocated in kernel.cpp.
I did not see that one coming.
This commit fixes some instances of uninitialized memory.
In addition, the bootstrap tables for x64 are moved around a bit,
in this awful game of placing stuff where it won't collide with grub.
This fixes issues where it did not fit into the first few MiB,
or that GRUB loaded it someplace weird.
The kernel heap is now also protected against growing into the
ramdisk and the kernel stack.
Fixed 64-bit-ness bug in BSR() and BSF().
Added 64-bit system call stubs in libmaxsi.
Added a Elf64 program loader.
Fixed uninitialized memory bug in the scheduler.
x64/boot.s now takes care of user-space memory permissions.
Fixed bug in x64/syscall.s
That's right. The system now boots in 64-bit mode.
It is horribly unstable, though.
