-*- 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.
