getting started: link to gdb step debug information

README.adoc

@@ -195,6 +195,8 @@ The link:build[] script is just a lightweight wrapper that calls the smaller bui
 ./build --dry-run
 ....
 
+When you reach difficulties, QEMU makes it possible to easily GDB step debug the Linux kernel source code, see: <<gdb>>.
+
 ===== Your first kernel module hack
 
 Edit link:kernel_modules/hello.c[] to contain:
@@ -251,6 +253,8 @@ If the guest and host are the same arch, typically x86_64, you can speed up boot
 
 All of this put together makes the safe procedure acceptably fast for regular development as well.
 
+It is also easy to GDB step debug kernel modules with our setup, see: <<gdb-step-debug-kernel-module>>.
+
 ===== Your first QEMU hack
 
 Not satisfied with mere software? OK then, let's hack up the QEMU x86 CPU identification:
@@ -293,6 +297,8 @@ The only thing you can do with open source is purely functional designs with lin
 
 If you really want to develop semiconductors, your only choice is to join an university or a semiconductor company that has the EDA licenses.
 
+While hacking QEMU, you will likely want to GDB step its source. That is trivial since QEMU is just another userland program like any other, but our setup has a shortcut to make it even more convenient, see: <<debug-the-emulator>>.
+
 ==== About the QEMU Buildroot setup
 
 This is our reference setup, and the best supported one, use it unless you have good reason not to.
@@ -3063,7 +3069,7 @@ Step debug also works:
 ;
 ....
 
-===== gem5 syscall emulation exit status
+==== gem5 syscall emulation exit status
 
 As of gem5 7fa4c946386e7207ad5859e8ade0bbfc14000d91, the crappy `se.py` script does not forward the exit status of syscall emulation mode, you can test it with: