通过串口调试FreeBSD内核的操作示例

雨丝风片

通过串口调试FreeBSD内核的操作示例

这个示例使用的是Windows vmware里的两台虚拟FreeBSD机器，演示通过串口调试FreeBSD内核的操作过程。内核版本为FreeBSD6.1。

1、调试环境的搭建

   首先是在vmware里面安装两台FreeBSD机器，并通过用命名管道模拟的“串口”将这两台机器连接起来，具体设置方法请参见vmware随机文档的“Connecting Two Virtual Machines ”一节。

2、FreeBSD调试内核的编译

   两台虚拟FreeBSD机器分别作为调试机和目标机。

(1)在调试机上构建自己的内核配置文件，假设名字为DEBUG_KERNEL：

1. #cd /usr/src/sys/i386/conf
   
2. #mkdir /root/kernels
   
3. #cp GENERIC /root/kernels/DEBUG_KERNEL
   
4. #ln -s /root/kernels/DEBUG_KERNEL

复制代码

(2)在调试机上编辑上述内核配置文件：

1. #vim DEBUG_KERNEL

复制代码

        在配置文件中加入以下选项：

1. makeoptions     DEBUG=-g
   
2. options         KDB
   
3. options         KDB_TRACE
   
4. options         DDB
   
5. options         GDB

复制代码

(3)在调试机上编译调试内核：

1. #/usr/sbin/config DEBUG_KERNEL
   
2. #cd ../compile/DEBUG_KERNEL
   
3. #make cleandepend
   
4. #make depend
   
5. $make

复制代码

(4)完成上述步骤之后，在调试机的当前目录（/usr/src/sys/i386/compile/DEBUG_KERNEL/）目录下就会生成kernel.debug文件。把这个文件拷贝到目标机上，放到/boot/kernel/目录下，更名为kernel，并使用strip -x去掉其中的调试符号。

3、完成调试机和目标机的远程连接

(1)编辑目标机的/boot/device.hints文件，找到0号串口标志对应的行，为其增加0x80标志，修改后该行如下：

1. hint.sio.0.flags="0x90"

复制代码

(2)另外，我所使用的FreeBSD6.1版本在进入DDB模式之后会失去键盘响应，这是由于DDB和kbdmux(4)共存还有问题。如果出现这一情况，解决办法是在目标机的/boot/device.hints文件中添加如下这一行：

1. hint.kbdmux.0.disabled="1"

复制代码

(3)重启目标机，在启动菜单中选择以下这一项：

1. 6. Escape to loader prompt

复制代码

       然后在“OK”提示符后输入boot -d ：

1. Type '?' for a list of commands, 'help' for more detailed help.
   
2. OK boot -d

复制代码

       这时就会出现如下画面：
     
       然后再依次输入“gdb”和“s”命令，使其进入等待远端gdb调试连接的状态。
     

( 4 )在调试机上，输入下述命令：

1. #kgdb -r /dev/cuad0 kernel.debug

复制代码

       稍等片刻，gdb就会完成和远端目标机的链接，出现如下画面：

1. # kgdb -r /dev/cuad0 kernel.debug
   
2. [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
   
3. GNU gdb 6.1.1 [FreeBSD]
   
4. Copyright 2004 Free Software Foundation, Inc.
   
5. GDB is free software, covered by the GNU General Public License, and you are
   
6. welcome to change it and/or distribute copies of it under certain conditions.
   
7. Type "show copying" to see the conditions.
   
8. There is absolutely no warranty for GDB.  Type "show warranty" for details.
   
9. This GDB was configured as "i386-marcel-freebsd".
   
10. Switching to remote protocol
    
11. kdb_enter (msg=0x2a "") at ../../../kern/subr_kdb.c:270
    
12. 270     }
    
13. #0  kdb_enter (msg=0x2a "") at ../../../kern/subr_kdb.c:270
    
14. 270     }
    
15. (kgdb)

复制代码

4、开始调试

现在我们在调试机上用bt命令就可以看到之前的调用序列：

1. (kgdb) bt
   
2. #0  kdb_enter (msg=0x2a "") at ../../../kern/subr_kdb.c:270
   
3. #1  0xc0843e92 in init386 (first=12734464) at ../../../i386/i386/machdep.c:2192
   
4. #2  0xc0446ded in begin () at ../../../i386/i386/locore.s:339
   
5. (kgdb)

复制代码

再设个断点试试。选择虚拟映射初始化函数vm_map_init()，设置断点，继续运行，我们就可以看到程序停止在了该函数处。然后继续使用了gdb的bt、s、list命令来测试查看调用栈、单步运行和列出源代码的功能。效果如下：

1. (kgdb) b vm_map_init
   
2. Breakpoint 1 at 0xc07c5203: file ../../../vm/vm_map.c, line 525.
   
3. (kgdb) c
   
4. Continuing.
   
5. [New Thread 0]
   
6. [Switching to Thread 0]
   
7. 
   
8. Breakpoint 1, vm_map_init (map=0xc098b3c0, min=0, max=3217031168) at ../../../vm/vm_map.c:525
   
9. 525             _vm_map_init(map, min, max);
   
10. (kgdb) bt
    
11. #0  vm_map_init (map=0xc098b3c0, min=0, max=3217031168) at ../../../vm/vm_map.c:525
    
12. #1  0xc0628120 in proc0_init (dummy=0x0) at ../../../kern/init_main.c:430
    
13. #2  0xc0627d6e in mi_startup () at ../../../kern/init_main.c:208
    
14. #3  0xc0446df5 in begin () at ../../../i386/i386/locore.s:348
    
15. (kgdb) s
    
16. _vm_map_init (map=0xc098b3c0, min=3231233212, max=3231233212) at ../../../vm/vm_map.c:512
    
17. 512             map->header.next = map->header.prev = &map->header;
    
18. (kgdb) list
    
19. 507      */
    
20. 508     static void
    
21. 509     _vm_map_init(vm_map_t map, vm_offset_t min, vm_offset_t max)
    
22. 510     {
    
23. 511
    
24. 512             map->header.next = map->header.prev = &map->header;
    
25. 513             map->needs_wakeup = FALSE;
    
26. 514             map->system_map = 0;
    
27. 515             map->min_offset = min;
    
28. 516             map->max_offset = max;
    
29. (kgdb)

复制代码

现在，我们再来看看目标机的输出信息：
   
    从图中我们可以看到，在遇到了vm_map_init()函数处的断点之后，目标机暂停在了系统初始化过程中。因此，通过这种方式，我们从系统初始化的时候就可以开始内核调试了。

[ 本帖最后由 雨丝风片 于 2006-9-4 13:24 编辑 ]

congli

学习ing!

雨丝风片

谨以此小贴庆祝俺在cu的一周岁生日。:em11:

windflying

高深的东西，看不懂，顶一下雨老大！

gvim

大哥，3下面的(1)说的是0x80，而下面的引用hint.sio.0.flags="0x90"怎么是0x90呢。
我大概看了<<debugging kernel problems>>，不过没看出什么所以然的东西来
这些调试方法唯一的不好在于不能调试陷入gdb之前的内核代码，如mmu的初始化。

雨丝风片

原帖由 gvim 于 2006-9-4 15:53 发表
大哥，3下面的(1)说的是0x80，而下面的引用hint.sio.0.flags="0x90"怎么是0x90呢。
我大概看了<<debugging kernel problems>>，不过没看出什么所以然的东西来
这些调试方法唯一的不 ...

因为我那个标志原来就是0x10，再加上一个0x80，结果就成了0x90了，呵呵。

至于这个0x10，指的是这个串口将作为串行控制台。按照【debugging kernel problems】作者的解释，是想保证在比较悲惨的情况下（比如已无法在“显示器”上看到系统状况），我们仍然能够通过传统的串行控制台看到系统的状况。不过我似乎还没有把系统折腾到这种地步过。。。

至于在begin() -> init386() -> kdb_enter() 之前的代码，不知道是否有其它方法进行调试？

大大狗

嘿嘿，学习一下。

调试对我来说是用不上了，重新优化一下内核我还是可以实现的。但是就是不知道优化内核后，
会有怎么样的变化呢。我怎么感觉没有什么变化呢（我是按handbook一步一步做的）。

雨丝风片

原帖由 gvim 于 2006-9-4 15:53 发表
这些调试方法唯一的不好在于不能调试陷入gdb之前的内核代码，如mmu的初始化。 ...

不过，在这之前的代码貌似不太多嘛。。。

gvim

原帖由 雨丝风片 于 2006-9-4 16:43 发表


因为我那个标志原来就是0x10，再加上一个0x80，结果就成了0x90了，呵呵。

至于这个0x10，指的是这个串口将作为串行控制台。按照【debugging kernel problems】作者的解释，是想保证在比较悲惨的情况下（比 ...

这样的嗦
gdb之前的代码我只调试过arm s3c2410 的NetBSD部分。我目前了解的方法只能用物理串口+printf调试。(因为在arm port里console在mmu初始化之前就初始化了)
什么时候空闲时间多就整理上来。

原帖由 大大狗 于 2006-9-4 16:48 发表
嘿嘿，学习一下。

调试对我来说是用不上了，重新优化一下内核我还是可以实现的。但是就是不知道优化内核后，
会有怎么样的变化呢。我怎么感觉没有什么变化呢（我是按handbook一步一步做的）。

我对内核tuning的所有知识都来自于http://www.netbsd.org/guide/en/chap-tuning.html 和 http://www.freebsd.org/doc/en_US ... /config-tuning.html ，感觉NetBSD的要说的详细写，推荐你看看(抛开系统差异，这些东西原理是通的)

gvim

原帖由 雨丝风片 于 2006-9-4 16:54 发表


不过，在这之前的代码貌似不太多嘛。。。

这段代码是VM系统的基础，而VM又是内核里最麻烦的东西
很多VM涉及的算法、组织等都清楚，可是真要说细节还只有从这里开始