Skip to main content
MVH Kernel compiles from a single, self-contained Makefile with no external build system, no package manager, and no generated configuration. You need a standard x86_64 GCC toolchain and GNU Make. This page covers every compiler flag the build uses, all Makefile targets, the output artifacts you will find after a successful build, and notes on behaviours you need to be aware of during development.

Toolchain requirements

If your host system’s native gcc does not support -m64 (for example, on a 32-bit host), install a x86_64-elf cross-compiler and set the CC variable when invoking make:

Building the kernel

Run make from the repository root:
The build system creates the build/ directory if it does not exist, compiles each source module into a .o object file, then links everything with linker.ld into the final kernel binary.

Makefile targets

Compiler flags

The Makefile applies the following CFLAGS to every C source file in the kernel:
The table below explains each flag and why it is required: Assembly source files (entry64.S and interrupt64.S) are assembled with only -m64 -c — the full CFLAGS are not applied to assembly.

Output artifacts

A successful make produces a single output file:
MVH Kernel does not include a bootloader. build/kernel.elf is the kernel binary only. You must load it with your own bootloader that enters x86_64 Long Mode, identity-maps the first GiB of physical memory, and jumps to _kernel64_start. See the Quickstart for integration instructions.
You can inspect the output binary with standard ELF tools:

Entry point

The kernel entry point is _kernel64_start, defined in src/entry64.S and declared as the ELF entry in linker.ld:
The kernel is linked at a base address of 0x200000 (2 MiB). The linker script arranges sections in the following order: The .text.entry section — containing _kernel64_start — is kept first within .text via a KEEP directive so the entry point always lands at the lowest address in the binary.

Kernel modules compiled

The Makefile compiles the following modules into the final binary:

Notes on faulttest

The faulttest and faulttest page shell commands intentionally halt the kernel. faulttest triggers an exception without a CPU error code to validate the exception-dispatch path. faulttest page triggers a page fault to validate CR2 reporting and page-fault error-code decoding. Do not run either command in a production or integration environment unless you intend to test panic handling and are prepared for the system to stop.