PhantomR wrote:
I'd really like to know how it gets to call code in that area, but I actually feel more like starting all over again and trying to understand better how to call the kernel.
That depends on your design, you have more options.
Things that you should be aware:
- the compiler compiles code for a specific CPU mode (real, protected, long) with a specific ABI
- parameter passing (the ABI) differs for all modes, and there are more standards (cdecl, pascal, stdcall, fastcall, SysV ABI etc.)
- your boot loader must set up an environment proper for your mode and ABI
- you can change mode within your kernel too (protmode-longmode trapoline is very common for example)
So for example, your loader can set up protected mode and you should compile your kernel's entry point in protmode, which is a small code that switches to long mode. Setting up protmode includes setting up GDT, stack, segment registers at minimum. In this case your entry point's ABI will differ from the normal ABI that your kernel uses.
You can also set up long mode in the loader, and have a cleanly 64 bit kernel (simplifies your kernel's toolchain a lot). In that case you have to set up GDT, stack, segment registers and paging as well in the loader, and if you choose fastcall or SysV ABI, you'll have to set up GPRs to pass arguments to your kernel's entry point (as first arguments are not passed on the stack).
You can use a specific, non-standard ABI for your kernel (like Multiboot tables for example), but I rather suggest to figure out which ABI your compiler is using, and set the arguments for that calling convention. Needs more background work, but pays out on the long run (as your entry point will receive it's parameters just like any other function, therefore your kernel became simpler and easier to debug).
Therefore the answer to the question "how to call the kernel" is:
1. set up CPU mode in your loader to match the one your compiler is using
2. set up arguments accoding to your choosen ABI (which may be different than the normal ABI in your kernel)
3. jump to the kernel's entry point
Cheers,
bzt