Kernel debugging in skas mode

Site Home Page The UML Wiki UML Community Site The UML roadmap What it's good for Case Studies Kernel Capabilities Downloading it Running it Compiling Installation Skas Mode Incremental Patches Test Suite Host memory use Building filesystems Troubles User Contributions Related Links The ToDo list Projects Diary Thanks Contacts
Tutorials The HOWTO (html) The HOWTO (text) Host file access Device inputs Sharing filesystems Creating filesystems Resizing filesystems Virtual Networking Management Console Kernel Debugging UML Honeypots gprof and gcov Running X Diagnosing problems Configuration Installing Slackware Porting UML IO memory emulation UML on 2G/2G hosts Adding a UML system call Running nested UMLs
How you can help Overview Documentation Utilities Kernel bugs Kernel projects
Screenshots A virtual network An X session
Transcripts A login session A debugging session Slackware installation
Reference Kernel switches Slackware README
Papers ALS 2000 paper (html) ALS 2000 paper (TeX) ALS 2000 slides LCA 2001 slides OLS 2001 paper (html) OLS 2001 paper (TeX) ALS 2001 paper (html) ALS 2001 paper (TeX) UML security (html) LCA 2002 (html) WVU 2002 (html) Security Roundtable (html) OLS 2002 slides LWE 2005 slides
Fun and Games Kernel Hangman Disaster of the Month
| ### Kernel debugging in skas mode Debugging UML in skas mode is pretty much the same as debugging a normal process, since, in skas mode, UML is pretty normal. You don't need the 'debug' switch on the command line, and you don't get gdb popping up in a new xterm. You start by running gdb on the UML binary and starting it running `host% gdb linux` `(host gdb) r ubd0=/home/jdike/roots/cow.debian,/home/jdike/roots/debian_22 con=port:9000 ssl=pty con0=fd:0,fd:1 umid=debian mem=128M` Also, have gdb ignore SIGSEGV and SUGUSR1 since these are used internally by UML, and your debugging session would otherwise be continually interrupted by them `(host gdb) handle SIGSEGV pass nostop noprint` `(host gdb) handle SIGUSR1 pass nostop noprint` If you've enabled both CONFIG_MODE_TT and CONFIG_MODE_SKAS, UML will exec itself, and gdb will see a SIGTRAP. ``
    Program received signal SIGTRAP, Trace/breakpoint trap.
    0xa000c000 in _start () at af_packet.c:1903
    1903    }
    (host gdb)
Just continue it if this happens. If CONFIG_MODE_TT is disabled, then UML will simply boot up. If you set any breakpoints before running UML, then all you need to do is get UML to hit one of them, and you will be bounced back to the gdb prompt for debugging. When you continue UML, you will be back to whatever UML prompt you had. If you need to interrupt UML, you can't ^C it because the terminal is in raw mode, and the ^C will just hit whatever UML is running. What you need to do is send the UML kernel thread a SIGINT from another shell. It is normally the first process after the gdb ``
    uml-2.5 8511: ps ux
    USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
    jdike     7132  7.6  2.5 15356 13276 pts/2   S    15:18   0:05 gdb linux
    jdike     7133  8.1  3.3 139544 17548 pts/2  R    15:18   0:05 /home/jdike/linux
    jdike     7139  5.7  0.1   840  752 pts/2    T    15:19   0:00 [linux]
    jdike     7144  0.2  3.3 139544 17548 pts/2  S    15:19   0:00 /home/jdike/linux
    jdike     7145  0.0  3.3 139544 17548 pts/2  S    15:19   0:00 /home/jdike/linux
The '[linux]' process is the userspace process, and the kernel process is the one immediately before it. `host% kill -INT 7133` `
    Debian GNU/Linux 2.2 usermode ttys/0

    usermode login:
    Program received signal SIGINT, Interrupt.
    0xa019a6c1 in __libc_nanosleep ()
    (gdb) bt
    #0  0xa019a6c1 in __libc_nanosleep ()
    #1  0xa00ed092 in idle_sleep (secs=10) at time.c:114
    #2  0xa00e5765 in cpu_idle () at process_kern.c:210
    #3  0xa000c50e in rest_init () at init/main.c:341
    #4  0xa000356d in start_kernel () at init/main.c:435
    #5  0xa00f38f7 in start_kernel_proc (unused=0x0) at process_kern.c:153
    #6  0xa00e52a2 in run_kernel_thread (fn=0xa00f38d0 <start_kernel_proc>,
        arg=0x0, jmp_ptr=0xa020c554) at process.c:239
    #7  0xa00f36de in new_thread_handler (sig=10) at process_kern.c:67
    #8  <signal handler called>
    #9  0xa01891d1 in __kill ()
    #10 0xa0188f85 in siglongjmp () at ../sysdeps/generic/longjmp.c:39
    #11 0xa00f32e3 in start_idle_thread (stack=0xa020e000,
        switch_buf_ptr=0xa020c57c, fork_buf_ptr=0xa020c580) at process.c:275
    #12 0xa00f3947 in start_uml_skas () at process_kern.c:169
    #13 0xa00ee779 in linux_main (argc=8, argv=0xbffff814) at um_arch.c:376
    #14 0xa000c3d2 in main (argc=8, argv=0xbffff814, envp=0xbffff838)
        at arch/um/main.c:143
    #15 0xa0188d52 in __libc_start_main (main=0xa000c1dc <main>, argc=8,
        ubp_av=0xbffff814, init=0xa01c6520 <_init>, fini=0xa01c6cb0 <_fini>,
        rtld_fini=0, stack_end=0xbffff80c) at ../sysdeps/generic/libc-start.c:129
    (gdb) c
    Continuing.

    Debian GNU/Linux 2.2 usermode ttys/0

    usermode login:
`

Hosted at