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 SourceForge Logo