OSDev.org

Hello everyone,

I've been following Brokenthorn's tutorial, but went for long mode instead. I can load an x86 kernel, but it has the following problems: I cannot use globals and function parameters, the kernel just crashes if I do. Also, I tried compiling the kernel as x64 instead (I am using VS2017) for this and in this case, the kernel does not load..

The kernel is loaded at 0x120000. Here's a picture of the loading part: https://imgur.com/a/jbbj5Qi ; IMAGE_PMODE_BASE holds the afore-mentioned address.
This is my kernel's main function (in the called main(), I try to print something to the screen.. it works, but not if try to access the parameters of any function or a global variable): http://prntscr.com/m6qsj4

I'm attaching logs of what Bochs gives me on each of the following cases:
1. x32 kernel when using a function parameter -> x32_using_function_parameter.txt
CODE SNIPPET: http://prntscr.com/m6qwkx
2. Also x32 kernel when writing to a global -> x32_writing_global.txt
CODE SNIPPET: http://prntscr.com/m6qz3u
3. x64 kernel.. doesn't properly call C? x64_kernel.txt
CODE SNIPPET: http://prntscr.com/m6r002


Should it matter, this is my GDT:
http://prntscr.com/m6qt6r
and this is my long mode setup routine:
http://prntscr.com/m6qtv8

Other than that, I'd like to note that visual studio warns me that I should use a load address higher than 4GB for best ASLR optimization. Also, the only pages I've allocated are those for identity mapping the first 2MiB's of memory.. could this be problematic?

Here's a link to my Bitbucket project (it's very messy, I really apologize).. to run it, one would have to set 'src/boot/boot.bin' as floppy drive A:'s boot sector and then one would run 'run.bat' (it requires Bochs to be intsalled). The 'root/failing.img' file contains a diskette image that has the bootsector written and the necessary files for the bootloader & kernel written to.
https://bitbucket.org/PhantomR13/cut2-myos/src/master/
EDIT: I apologize, I've just now pushed the files to the repository.. sorry for the delay.

Thank you so much!

PhantomR wrote:I've been following Brokenthorn's tutorial,

Beware: most OSDev tutorials are written by absolute beginners who don't know any more about OS development than you do. Here's what we know is wrong with the BrokenThorn tutorial. There may be other issues besides the ones listed on that page.

PhantomR wrote:I can load an x86 kernel, but it has the following problems: I cannot use globals and function parameters, the kernel just crashes if I do.

Isn't your bootloader setting the CPU to long mode? You can get pretty far running 32-bit code in 64-bit mode, but eventually it will crash.

PhantomR wrote:I'm attaching logs of what Bochs gives me on each of the following cases:

All three of those logs say the same thing: You've crashed because you're trying to execute something that isn't real code. (The address 0x40E is somewhere in the BIOS data area.) Since you're using Bochs, you can use the Bochs debugger to figure out how you got there.

PhantomR wrote:Other than that, I'd like to note that visual studio warns me that I should use a load address higher than 4GB for best ASLR optimization. Also, the only pages I've allocated are those for identity mapping the first 2MiB's of memory.. could this be problematic?

As long as the 2MiB covers the code and data you're using, it's fine. I don't know about the ASLR error; it might indicate that your OS requires runtime relocation. (Most OS developers use GCC or Clang instead of MSVC, since MSVC is not very friendly for OS development.)

Thank you very much for your help. 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.

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

Thank you! I really didn't pay much attention to the calling convention set up in the VS compiler. I'll definitely keep an eye out for these things when I get to the kernel part (I started over ). I'd like to go into long mode before jumping to the kernel so that I don't have to create both long mode and protected mode GDTs.