Linux的内核和System Call不好调试，参考这里：
http://stackoverflow.com/questions/5999205/cannot-step-into-system-call-source-code
简单来说，如果想在本机调试system call，那么当你进入system call时，系统已经在挂起状态了，那么它又怎样能响应用户的输入？
所以，有一个UML（http://user-mode-linux.sourceforge.net/）的方式，把内核当成一个进程启动，这样就可以在本机调试。
否则，只能通过串口，或者网络等从不同的机器来调试。
自己用KGdb和Vmware虚拟机折腾了下用串口调试Linux system call。总结一下。
编绎内核
首先，在虚拟机里安装好linux系统（注意把硬盘空间选择大点），编绎带Debug信息的内核：
先下载相关的包，及当前内核的源代码，注意用apt-get source下载源代码时，是放在当前目录下的。
mkdir code cd code sudo apt-get dpkg-dev sudo apt-get source linux-image-$(uname -r) sudo apt-get install libncurses5-dev sudo apt-get install bc再配置编绎选项：
sudo make menuconfig会有一个界面，可以自己设置编绎选项。在“Kernel hacking”下, 有KGDB的选项，不过貌似默认都选好了。
执行make编绎，再执行
sudo make make modules_install //编绎模块我编绎花了3,4个小时，编绎出来竟然有11G。。
把这些编绎好的数据复制一份到宿主机上，等下调试的时候要用到。
为虚拟机配置串口
在Vmware的“Settings”，“Hardware”，点“add"，选择”Serial Port“，再”output to socket"，在“Socket(named pipe)”里，填上“/tmp/testsocket”。则虚拟机里的串口数据会写到/tmp/testsocket这个文件里。
配置新内核启动
编绎好了内核，要用新内核，最简单的办法是直接切换到root用户：
make install会自动复制vmlinuz，.config, initrd.img等文件到boot目录下，并默认以新内核启动。
仅以新内核启动还不可以调试，修改/boot/grub/grub.cfg 文件，在"linux"命令下增加kgdb参数，如：
linux /boot/vmlinuz-3.13.0-24-generic root=UUID=xxx-b91d-xxx-839d-xxxxxx ro quiet kgdboc=ttyS1,115200 kgdbwait如果只是不想启动时等待，可以去掉kgdbwait参数。
重启虚拟机，可以发现停在这样的画面上：
用socat来传输串口数据到PTS
虚拟机已经在暂停，等待我们的连接了。先用socat来把虚拟机的串口输出传送到pts上(可以用man pts 查看pts的更多信息）。
用ctrl + alt + f1，进入tty1，再输入下面的命令：
sudo socat -d -d /tmp/testsocket PTY
如果成功的话，我们可以看到类似这样的输出：
successfully connected ... PTY is /dev/pts/14
用gdb连接pts，并调试
切换到root用户，进入到从虚拟机复制出来的编绎好的代码目录，执行：
gdb ./vmlinux
如果不加载vmlinux文件的话，则打不了断点。在gdb里再输入
Remote debugging using /dev/pts/14 continue
然后可以看到虚拟机里的linux开启正常启动了。
注意，如果是想在system call上打断点，则要在原来函数名前加上“sys_”。如
break sys_open
在gdb里输入continue之后，发现没有办法再打断点了，可以在虚拟机里以root用户执行：
echo g > /proc/sysrq-trigger
这样就可以让虚拟机暂停，在宿主机的gdb里可以重新操作了。
参考：
http://www.opensourceforu.com/2011/03/kgdb-with-virtualbox-debug-live-kernel/#http://www.eetop.cn/blog/html/21/766721-25573.html
http://blog.csdn.net/u011839461/article/details/12002075
http://wenku.baidu.com/view/baf6af3f0912a21614792996.html
http://my.oschina.net/fgq611/blog/113249
http://blog.csdn.net/star_xiong/article/details/17357821
