今天的特别汗，首先，之前UML在64位系统下没有编译通过，编译器和内核源码都应该不会犯这样低级的错误，那最有可能的原因就是gcc版本和 linux内核版本不匹配，gcc 4.4.4版本算是高版本了，而内核版本2.6.34已非最新，抱着侥幸心里下载了2.6.36版本编译，居然顺利通过，看来64位与32位编译并没什么 区别。

另外一个问题是昨天启动UML失败的问题，原来是我的命令行写错了，ubda指定根文件系统，我错写成了udba，以至无法加载文件系统，经过纠正后的命令如下：

当然这也不存在内核配置错误的问题了，至于根文件系统需要慢慢积累。

接下来看看如何调试内核，由官方文档 Kernel Hacking with UML 所言，直接使用 gdb linux 便可调试，不过我在启动一开始便遇到段错误，单步运行居然还能继续，之后便陷入无休止的trap中。

继续 google（最能找到答案的往往在国外的论坛，而且常常需要翻墙），最后找到两个设置，是SIGSEGV和SIGUSR1信号不中断继续运行，最终居然可以，这点让人百思不得其解，还是先看看现象如何：

居然一切顺利的断到了start_kernel，哈哈，不管如何，总算能够调试内核了。接下来还有UML虚拟机的网络配置，UML使用了一个取巧的方式就是利用 tun 和 iptables ，好在我也研究了大半年，明天继续。

今天唯一不明白的地方在于GDB调试的问题，明明遇到了SIGSEG，为什么还能继续呢？莫非这个信号是自己发出的？还有之后的SEGTRAP信号是怎么发出来的？要弄清楚这个问题，或许还得查阅UML代码。