-*- emacs-wiki -*-



                         Debugging the kernel with GDB (skas0/skas3)

   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.

   Start the UML for the test case manually:
                east single

   Note the PID of the main thread:
                cat ~/.uml/east/pid
                24789

   Attach to the pid:
          gdb> attach 24789
               handle SIGSEGV noprint nostop
               handle SIGUSR1 noprint nostop
           
   At this point, break points should be created as appropriate.


   If you want to send packets in as well, see [[DebuggingKernelNetJig]]   


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.