# Linux Kernel Module Cheat

#### 3.5.1. Linux kernel entry point

TODO https://stackoverflow.com/questions/2589845/what-are-the-first-operations-that-the-linux-kernel-executes-on-boot

As mentioned at: GDB step debug early boot, the very first kernel instructions executed appear to be placed into memory at a different location than that of the kernel ELF section.

As a result, we are unable to break on early symbols such as:

    ./run-gdb extract_kernel
    ./run-gdb main

gem5 ExecAll trace format>> however does show the right symbols however! This could be because gem5 uses vmlinux to boot, which QEMU uses the compressed version, and as mentioned on the Stack Overflow answer, the entry point is actually a tiny decompresser routine.

I also tried to hack `run-gdb` with:

    @@ -81,7 +81,7 @@ else
     ${gdb} \
     -q \\
     -ex 'add-auto-load-safe-path $(pwd)' \\
    --ex 'file vmlinux' \\
    +-ex 'file arch/arm/boot/compressed/vmlinux' \\
     -ex 'target remote localhost:${port}' \\
     ${brk} \
     -ex 'continue' \\

and no I do have the symbols from `arch/arm/boot/compressed/vmlinux'`, but the breaks still don’t work.

v4.19 also added a `CONFIG_HAVE_KERNEL_UNCOMPRESSED=y` option for having the kernel uncompressed which could make following the startup easier, but it is only available on s390. `aarch64` however is already uncompressed by default, so might be the easiest one. See also: Section 17.20.1, “vmlinux vs bzImage vs zImage vs Image”.

You then need the associated `KERNEL_UNCOMPRESSED` to enable it if available:

    config KERNEL_UNCOMPRESSED
        bool "None"
        depends on HAVE_KERNEL_UNCOMPRESSED

- arm64 secondary CPU entry point