我们在前面搭建UML环境，其中一个目的是为了调试内核，让我们在用户态里对Kernel相关问题进行模拟调试学习，接下来就让我们初尝下如何使用gdb来调试UML。
1.运行UML并确认其对应的进程打开一终端，使用./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256m命令运行起UML后，再打开另一终端，并运行ps uf | grep linux | grep -v grep | grep -v git命令，会有如下输出：xinu@slam:~$ ps uf | grep linux | grep -v grep | grep -v gitxinu 7160 4.2 1.7 276996 36476 pts/5 S+ 16:05 0:17 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 7167 0.0 1.7 276996 36476 pts/5 S+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 7168 0.0 1.7 276996 36476 pts/5 S+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 7169 0.0 1.7 276996 36476 pts/5 S+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 7170 0.0 0.0 15528 972 pts/5 t+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 7359 0.0 0.0 15804 1124 pts/5 t+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 7432 0.0 0.0 15552 840 pts/5 t+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 7439 0.0 0.0 15512 848 pts/5 t+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 9501 0.0 0.0 16352 692 pts/5 t+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 9581 0.0 0.0 15572 988 pts/5 t+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 9632 0.0 0.0 15568 1024 pts/5 t+ 16:05 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 9639 0.0 0.0 16212 1340 pts/5 t+ 16:06 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256mxinu 9641 0.0 0.0 16676 2020 pts/5 t+ 16:06 0:00 \_ ./linux ubda=../Debian-Wheezy-AMD64-root_fs mem=256m从上面的输出内容可知对应主进程的PID为7160。
2.连接调试使用GDB连接上已运行的UML环境并进行调试尝试。在新打开的另一终端输入如下命令：sudo gdb -p 7160此时如果gdb attach上UML后会有如下输出（注意需root权限）：xinu@slam:~$ sudo gdb -p 7160[sudo] password for xinu:GNU gdb (GDB) 7.6.1-ubuntuCopyright (C) 2013 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or laterThis is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Type 'show copying'and 'show warranty' for details.This GDB was configured as 'x86_64-linux-gnu'.For bug reporting instructions, please see:.Attaching to process 7160Reading symbols from /home/xinu/Linux内核启示说/build/uml/linux-3.13.6/linux...done.Reading symbols from /lib/x86_64-linux-gnu/libutil.so.1...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libutil-2.17.so...done.done.Loaded symbols for /lib/x86_64-linux-gnu/libutil.so.1Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.17.so...done.done.Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.17.so...done.done.Loaded symbols for /lib64/ld-linux-x86-64.so.2Reading symbols from /lib/x86_64-linux-gnu/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libnss_compat-2.17.so...done.done.Loaded symbols for /lib/x86_64-linux-gnu/libnss_compat.so.2Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libnsl-2.17.so...done.done.Loaded symbols for /lib/x86_64-linux-gnu/libnsl.so.1Reading symbols from /lib/x86_64-linux-gnu/libnss_nis.so.2...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libnss_nis-2.17.so...done.done.Loaded symbols for /lib/x86_64-linux-gnu/libnss_nis.so.2Reading symbols from /lib/x86_64-linux-gnu/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libnss_files-2.17.so...done.done.Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.20x00007fd1da9f9840 in __nanosleep_nocancel ()at ../sysdeps/unix/syscall-template.S:8181 ../sysdeps/unix/syscall-template.S: No such file or directory.(gdb)连接上后，我们就开始尝试了，在上面的(gdb)后面运行指令set follow-fork-mode parent，确保等会gdb一直在该进程，即在fork创建新的子进程后继续调试父进程，子进程不受影响。接下来，在(gdb)后面继续运行指令break sys_clone创建一个断点，此时会输出如下内容：(gdb) break sys_cloneBreakpoint 1 at 0x6003526d: file kernel/fork.c, line 1679.接下来在(gdb)后面继续运行info break查看刚创建的断点，有如下内容输出：(gdb) info breakNum Type Disp Enb Address What1 breakpoint keep y 0x526d in SyS_cloneat kernel/fork.c:1679接下来在(gdb)后面输入continue，让程序继续运行，处于被调试状态，此时会有如下内容输出：(gdb) continueContinuing.接下来在运行起来的UML里输入命令ls -l，会有如下内容输出：root@changeme:~# ls -l此时没有任何输出，一直处于闪烁光标等待内容输出的状态，而gdb端有如下输出：(gdb) continueContinuing.Breakpoint 1, SyS_clone (clone_flags=18874385, newsp=0, parent_tidptr=0,child_tidptr=1, tls_val=0) at kernel/fork.c:16791679 SYSCALL_DEFINE5(clone, unsigned long, clone_flags, unsigned long, newsp,(gdb)即此时在UML里运行的ls -l命令停在了刚在gdb设置的断点处，接下来我们可以在gdb里查看断点处的相关信息，在(gdb)后面输入l后会有如下输出：(gdb) l1674 int, stack_size,1675 int __user *, parent_tidptr,1676 int __user *, child_tidptr,1677 int, tls_val)1678 #else1679 SYSCALL_DEFINE5(clone, unsigned long, clone_flags, unsigned long, newsp,1680 int __user *, parent_tidptr,1681 int __user *, child_tidptr,1682 int, tls_val)1683 #endif(gdb)此时可以看到断点所在1679行处前后的相关代码行源码，便于我们定位问题。至此，演示了在用户空间下调试UML里Kernel，体验了个回gdb。END