Some hardware/software configurations crash KVM as soon as we try to
start Serenity. The exact cause is currently unknown, so just fully
revert it for now.
This reverts commit 897c4e5145.
The new baked image is a Prekernel and a Kernel baked together now, so
essentially we no longer need to pass the Prekernel as -kernel and the
actual kernel image as -initrd to QEMU, leaving the option to pass an
actual initrd or initramfs module later on with multiboot.
Target GDB is only used for debugging the kernel, which is not relevant
to most people. Starting with 924758c6f8, GDB would always be built
as part of the toolchain if the user didn't have it installed. This is
unnecessary.
This commit adds a separate script for building GDB, which the user
needs to explicitly invoke. A message is added to Meta/debug-kernel.sh
which alerts the user to this fact.
Previously, we would unconditionally build GDB from source for the
AArch64 toolchain. This commit makes it possible to use the system's
`gdb` binary if it supports the architecture, or `aarch64-elf-gdb` if
such a package is installed.
An `aarch64-elf-gdb` package will be available through Homebrew once
this PR is merged: https://github.com/Homebrew/homebrew-core/pull/127323
This is a preparation to check if our users find noticeable bugs in the
x86-64 target, before we can decide if we want to remove the i686 target
for good.
We now pass along the toolchain type to all subcommands. This ensures
that gdb will load the correct debug information for kernels compiled
with Clang, and the following warning won't appear with the GNU
toolchain:
> WARNING: unknown toolchain 'gdb'. Defaulting to GNU.
> Valid values are 'Clang', 'GNU' (default)
Previously debug-kernel.sh wouldn't detect source if you launched the
script from the wrong path. By explicitly setting the name, source will
be loaded by gdb in all situations.
The function arguments almost always optimized away, so you never get
much value out of showing these in the default back trace view, it just
adds a bunch of extra stuff that you need to visual wade through.
So lets disable showing them.
This enables further work on implementing KASLR by adding relocation
support to the pre-kernel and updating the kernel to be less dependent
on specific virtual memory layouts.
This implements a simple bootloader that is capable of loading ELF64
kernel images. It does this by using QEMU/GRUB to load the kernel image
from disk and pass it to our bootloader as a Multiboot module.
The bootloader then parses the ELF image and sets it up appropriately.
The kernel's entry point is a C++ function with architecture-native
code.
Co-authored-by: Liav A <liavalb@gmail.com>
Multiboot only supports ELF32 executables. This changes the build
process to build an ELF32 executable which has a 32-bit entry point,
but consists of mostly 64-bit code.
