mirror of
https://gitlab.com/sortix/sortix.git
synced 2023-02-13 20:55:38 -05:00
36b01eb2d3
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. |
||
|---|---|---|
| .. | ||
| base.s | ||
| bits.h | ||
| boot.s | ||
| gdt.s | ||
| interrupt.s | ||
| memorymanagement.cpp | ||
| memorymanagement.h | ||
| process.cpp | ||
| scheduler.cpp | ||
| syscall.s | ||
| thread.cpp | ||
| x64.cpp | ||
| x64.h | ||