-*- emacs-wiki -*- Debugging the kernel with GDB (tt-mode) With User-Mode-Linux, you can debug the kernel using GDB. See http://user-mode-linux.sourceforge.net/debugging.html . Typically, one will want to address a test case for a failing situation. Running GDB from Emacs, or from other front ends is possible. First start GDB. Tell it to open the UMLPOOL/swan/linux program. Note the PID of GDB: marajade-[projects/freeswan/mgmt/planning] mcr 1029 %ps ax | grep gdb 1659 pts/9 SN 0:00 /usr/bin/gdb -fullname -cd /mara4/freeswan/kernpatch /UMLPOOL/swan/ linux Set the following in the environment: UML_east_OPT="debug gdb-pid=1659" Then start the user-mode-linux in the test scheme you wish: marajade-[kernpatch/testing/klips/east-icmp-02] mcr 1220 %../../utils/runme.sh The user-mode-linux will stop on boot, giving you a chance to attach to the process: (gdb) file linux Reading symbols from linux...done. (gdb) attach 1 Attaching to program: /mara4/freeswan/kernpatch/UMLPOOL/swan/linux, process 1 0xa0118bc1 in kill () at hostfs_kern.c:770 At this point, break points should be created as appropriate. Other notes about debugging If you are running a standard test, after all the packets are sent, the UML will be shutdown. This can cause problems, because the UML may get terminated while you are debugging. The environment variable NETJIGWAITUSER can be set to "waituser". If so, then the testing system will prompt before exiting the test. The environment variable UML_GETTY if set, will cause each UML to spawn a getty on /dev/tty1, and will wait for it to exit before continuing. The environment variable UML_SLEEP can be set to some shell code. It will be invoked at the end of each UML run. In general, this is used in interactive UML use, so that the window in which the UML was running won't close immediately. While a good value should be: "echo press enter; read ans", something about the way the UML exits when it panics (oops) means that the tty is too broken for this to work, so use "sleep 180" instead.