# Linux Kernel Module Cheat
The perfect emulation setup to study and develop the <<linux-kernel>> v5.9.2, kernel modules, <<qemu-buildroot-setup,QEMU>>, <<gem5-buildroot-setup,gem5>> and x86_64, ARMv7 and ARMv8 <<userland-assembly,userland>> and <<baremetal-setup,baremetal>> assembly, <<c,ANSI C>>, <<cpp,C++>> and <<posix,POSIX>>. <<gdb>> and <<kgdb>> just work. Powered by <<about-the-qemu-buildroot-setup,Buildroot>> and <<about-the-baremetal-setup,crosstool-NG>>. Highly automated. Thoroughly documented. Automated <<test-this-repo,tests>>.

### 11.5. User mode static executables

Example:

    ./build-userland \
      --arch aarch64 \
      --static \
    ;
    ./run \
      --arch aarch64 \
      --static \
      --userland userland/c/command_line_arguments.c \
      --cli-args 'asdf "qw er"' \
    ;

Running dynamically linked executables in QEMU requires pointing it to the root filesystem with the `-L` option so that it can find the dynamic linker and shared libraries, see also:

- https://stackoverflow.com/questions/54802670/using-dynamic-linker-with-qemu-arm/64551293#64551293

- https://stackoverflow.com/questions/khow-to-gdb-step-debug-a-dynamically-linked-executable-in-qemu-user-mode

We pass `-L` by default, so everything just works.

However, in case something goes wrong, you can also try statically linked executables, since this mechanism tends to be a bit more stable, for example:

- QEMU x86_64 guest on x86_64 host was failing with stack smashing detected when using glibc, but we found a workaround

- gem5 user only supported static executables in the past, as mentioned at: Section 11.7, “gem5 syscall emulation mode”

Running statically linked executables sometimes makes things break:

- User mode static executables with dynamic libraries

- TODO understand why:

      ./run --static --userland userland/c/file_write_read.c

  fails our assertion that the data was read back correctly:

      Assertion `strcmp(data, output) == 0' faile

- User mode static executables with dynamic libraries