Bare metal projects are always a fun hobby. I've done some projects like this in the past [0], let me share some things I learned the hard way.
If the author is reading, here are a few corrections.
> char * vidptr = (char * )0xb8000;
This needs "volatile" qualifier or all the writes to video memory will be dropped when optimization is enabled.
Memory mapped I/O like this is one of the few use cases where you need "volatile" in C.
> gcc -m32 -c kernel.c -o kc.o
You need to build a cross-compiler for bare metal projects. Using the system gcc will not work in the long run. The compiler packaged with your operating system is intended for building binaries for use with your operating system. It may have downstream patches or configured to a target in a way that will cause problems.
The worst part is that it may seem to work for a while, until it doesn't. I ran into some hard-to-debug issues with my past projects and learned this the hard way. If I recall correctly, the issues were related to redzones and ABI conventions.
You need to build GNU binutils and GCC for the "i686-pc-elf" target. I documented this process for someone else's bare metal project here [1].
It really pays off to do this right from the start. Once you have a cross-compiler and a build system that can produce debuggable elf images (you also need to build gdb for the target), things get much easier. Using the built-in debuggers in QEMU or Bochs can only get you so far. Having a proper debugger with symbols and source view will make working much easier.
For a build system, plain old Makefiles work best, CMake and other high level build systems are a pain in the ass with bare metal projects that require linker scripts, etc.
> You need to build GNU binutils and GCC for the "i686-pc-elf" target.
coreboot has similar issues, and so we maintain our cross compiler building script for 10 years now[0] (although historically using i386-elf instead of i686-*-elf).
I sometimes wonder if there's value in packaging our compilers (all 8 architectures) for other users.
FWIW, the need to bootstrap a cross-compiler from source is not inherent to cross-compilers; it's possible to implement a compiler in such a way that every version of the compiler is automatically a cross-compiler.
I remember a few years back when I was trying to play with MINIX. Tanenbaum got several million EUR and hired some grad students to work on the thing. They promptly replaced much of the system with NetBSD. ("Perhaps too much", you can hear Tanenbaum say in one of his talks.) As a result of this the system compiler ACK was switched out for LLVM/clang. I complained on the mailing list about this because a full system build from source is something that used to be doable in <10 minutes—something Tanenbaum used to boast about—and it was now taking 3 hours if you decided to blow away your source/build directory and do a from-scratch build. The worst part is that the MINIX core, i.e., all the interesting parts, still only accounted for ~10 minutes of that build time, and virtually all the rest was spent compiling and then recompiling LLVM. The response I got from one of the aforementioned grad students was that this is "just how cross-compilers work". No, pal; that's how the compiler that you chose works.
The Plan 9 compilers work exactly like this, every compile is a cross-compile. It's extremely convenient because you can do all of your builds on your really fast machine for all of your other machines or if you're using a slow machine. It's one of the reasons I can live happily with a raspberry pi as one of my main workstations. All you need to do to build for a different target is change $objtype.
Afaik LLVM/Clang doesn't need bootstrapping from source for cross-compiling, but you can choose to include/exclude target support at build time. GCC and binutils can only have one target.
Was the LLVM/Clang build done for building a cross compiler to build Minix or was it to build a compiler that runs on Minix? The latter would be unavoidable, but for the former just having LLVM pre-installed on the build machine should do.
>"I remember a few years back when I was trying to play with MINIX. Tanenbaum got several million EUR and hired some grad students to work on the thing."
This piqued my interest, what was this project exactly? Can you elaborate on this anecdote?
the unix x86_64 userspace abi guarantees that the 128 bytes (known as the red zone) above the stack pointer are guaranteed not to be clobbered by signal handlers. This an optimization that avoid the need for leaf functions to manipulate the stack pointer to allocate their stack frame.
The linux kernel does not follow this part of the ABI, so the compiler needs to be told that there is no red zone or functions will randomly see their stack frame clobbered by interrupt handlers.
> The linux kernel does not follow this part of the ABI, so the compiler needs to be told that there is no red zone or functions will randomly see their stack frame clobbered by interrupt handlers.
You're absolute right, but I would add a qualifier that it is impossible for a kernel to use the redzone optimization. Certain architectures (Like x86) will push data onto the stack when an interrupt happens and there is no way to tell them to put that data after the first 128 bytes on the stack.
Doesn't red-zoning break the fundamental contract of a stack pointer -- i.e., that it marks the end of the stack (and hence the location of the next item to be pushed)? This feature sounds like a bug to me...
In some ways yes, but it is only applied to functions where they call no other functions and thus "nobody" will ever know they never moved the stack pointer anyway. In those situations moving the stack pointer is just pointless extra work because it is a value that will never be used and then just restored to its original value.
I say "nobody" because in particular signal handlers (Which are basically just userland interrupts) can interrupt any part of userland code. However since they are generated entirely by the kernel it is easy enough for the kernel to obey the redzone and place the signal handler 128 bytes above the stack pointer, so in practice this isn't that big of a deal.
If the author is reading, here are a few corrections.
> char * vidptr = (char * )0xb8000;
This needs "volatile" qualifier or all the writes to video memory will be dropped when optimization is enabled.
Memory mapped I/O like this is one of the few use cases where you need "volatile" in C.
> gcc -m32 -c kernel.c -o kc.o
You need to build a cross-compiler for bare metal projects. Using the system gcc will not work in the long run. The compiler packaged with your operating system is intended for building binaries for use with your operating system. It may have downstream patches or configured to a target in a way that will cause problems.
The worst part is that it may seem to work for a while, until it doesn't. I ran into some hard-to-debug issues with my past projects and learned this the hard way. If I recall correctly, the issues were related to redzones and ABI conventions.
You need to build GNU binutils and GCC for the "i686-pc-elf" target. I documented this process for someone else's bare metal project here [1].
It really pays off to do this right from the start. Once you have a cross-compiler and a build system that can produce debuggable elf images (you also need to build gdb for the target), things get much easier. Using the built-in debuggers in QEMU or Bochs can only get you so far. Having a proper debugger with symbols and source view will make working much easier.
For a build system, plain old Makefiles work best, CMake and other high level build systems are a pain in the ass with bare metal projects that require linker scripts, etc.
[0] https://github.com/rikusalminen/danjeros [1] https://github.com/Overv/MineAssemble/blob/master/README.md