whoops
Turns out, when testing the new debug write syscall, it was slightly broken when passing wrong params, specifially when passing an unmapped or invalid address as a pointer to the string to write. Because of that, a page fault was triggered in the syscall, which blew up the stack, which was for some reason already filled more than halfway (around 9 KiB)?!?
Side note: in a syscall handler, there are only 16 KiB of stack memory available, and therefore 9 KiB before any error handling is already kind of a lot (normally it should be less than half in this application)
What was actually wrong
Turns out, the error was the freaking kprint stuff. Yes, the funny kdebug!() and knotice!() logging macros.. The main issue is that they’re macros, which expand in place.
Why that’s a problem
In Syscall::dispatch, there’s two kdebug!() calls. That blows the method’s needed stack to almost 5 KiB for a simple dispatcher function with 10 lines, which is unacceptable. The problem is that the stack memory for all the kdebug!() writes gets reserved as soon as the method is called, and each kprint macro call has a 2 KiB buffer and more behind it that it needs.
The Solution
To fix this, I replaced the internal __kprint macro with a function. This means that now the needed stack for the logging action is only reserved during the logging, not during the whole parent function.
By doing this, I managed to cut the debug write system call’s memory footprint from around 8 KiB to just 1.5 KiB, which is a huge improvement.
