Chinaunix首页 | 论坛 | 博客
  • 博客访问: 172495
  • 博文数量: 41
  • 博客积分: 445
  • 博客等级: 下士
  • 技术积分: 280
  • 用 户 组: 普通用户
  • 注册时间: 2010-03-22 14:54
文章分类

全部博文(41)

文章存档

2015年(9)

2014年(7)

2013年(4)

2012年(21)

我的朋友

分类: LINUX

2013-05-22 09:54:31

一、调试前的准备
   内核级bug具有行为不可靠定义不清晰或者说很难再现的诸多特定,为内核级的bug跟踪和调试带来了很大的困难。
   ※ 对于一些定义不清楚地bug,问题的关键就是找到bug的源头,很多时候,当你精确地重现一个bug的时候,你就离成功不远了。
 
二、内核中的bug
   从隐藏在源代码中的错误到展现在目击者面前的bug,其发作往往是一系列连锁反应的事件才可能出发的。
   虽然内核调试有一定的困难,但是通过你的努力和理解,说不定你会喜欢上这样的挑战
 
三、printk( )
 内核提供的格式化打印函数。
 1、printk函数的健壮性
    健壮性是printk最容易被接受的一个特质,几乎在任何地方,任何时候内核都可以调用它(中断上下文、进程上下文、持有锁时、多处理器处理时等)。
   ※ 在系统启动过程中,终端初始化之前,在某些地方是不能调用的。
 
 2、记录等级
    printk函数可以指定一个记录级别,内核根据这个级别来判断是否在终端上打印消息。
    记录级别定义在中:
    
#define    KERN_EMERG    "<0>"   /* system is unusable */
#define    KERN_ALERT    "<1>"    /* action must be taken immediately    */
#define    KERN_CRIT        "<2>"    /* critical conditions */
#define    KERN_ERR        "<3>"    /* error conditions    */
#define    KERN_WARNING    "<4>"    /* warning conditions */
#define    KERN_NOTICE   "<5>"    /* normal but significant condition    */
#define    KERN_INFO        "<6>"    /* informational */
#define    KERN_DEBUG    "<7>"   /* debug-level messages    */
 
 调用方式:printk(KER_DEBUG “This is a debug notice!/n”);
 内核用这个指定的纪录等级和当前终端的纪录等级console_loglevel比较,来决定是不是向终端打印。
 
 关于< linux/kernel.h >的console_loglevel 定义:
 #define console_loglevel (console_printk[0])
 定义:
 int console_printk[4] = {
           DEFAULT_CONSOLE_LOGLEVEL,  /* console_loglevel */
           DEFAULT_MESSAGE_LOGLEVEL, /* default_message_loglevel */
           MINIMUM_CONSOLE_LOGLEVEL,  /* minimum_console_loglevel */
           DEFAULT_CONSOLE_LOGLEVEL, /* default_console_loglevel */
 };
 
 3、记录缓冲区
   内核消息都被保存在一个LOG_BUF_LEN大小的环形队列中。
   关于LOG_BUF_LEN定义:
   #define __LOG_BUF_LEN     (1 << CONFIG_LOG_BUF_SHIFT)
   ※ 变量CONFIG_LOG_BUF_SHIFT在内核编译时由配置文件定义,对于i386平台,其值定义如下(在linux26/arch/i386/defconfig中):
   CONFIG_LOG_BUF_SHIFT=18
 
   记录缓冲区操作
   ①、消息被读出到用户空间时,此消息就会从环形队列中删除。
   ②、当消息缓冲区满时,如果再有printk()调用时,新消息将覆盖队列中的老消息。
   ③、在读写环形队列时,同步问题很容易得到解决。
   ※ 这个纪录缓冲区之所以称为环形,是因为它的读写都是按照环形队列的方式进行操作的。
 
 4、syslogd和klogd
   在标准的Linux系统上,用户空间的守护进程klogd从纪录缓冲区中获取内核消息,再通过syslogd守护进程把这些消息保存在系统日志文件中。klogd进程既可以从/proc/kmsg文件中,也可以通过syslog()系统调用读取这些消息。默认情况下,它选择读取/proc方式实现。klogd守护进程在消息缓冲区有新的消息之前,一直处于阻塞状态。一旦有新的内核消息,klogd被唤醒,读出内核消息并进行处理。默认情况下,处理例程就是把内核消息传给syslogd守护进程。
   syslogd守护进程一般把接收到的消息写入/var/log/messages文件中。不过,还是可以通过/etc/syslog.conf文件来进行配置,可以选择其他的输出文件。
  图1 X光了此过程:
  
 
四、OOPS
 OOPS(也称 Panic)消息包含系统错误的细节,如 CPU 寄存器的内容等。是内核告知用户有不幸发生的最常用的方式。
 内核只能发布OOPS,这个过程包括向终端上输出错误消息,输出寄存器保存的信息,并输出可供跟踪的回溯线索。通常,发送完OOPS之后,内核会处于一种不稳定的状态。
 OOPS的产生有很多可能原因,其中包括内存访问越界或非法的指令等。
 ※ 作为内核的开发者,必定将会经常处理OOPS。
 ※ OOPS中包含的重要信息,对所有体系结构的机器都是完全相同的:寄存器上下文和回溯线索(回溯线索显示了导致错误发生的函数调用链
 
 1、ksymoops
    在 Linux 中,调试系统崩溃的传统方法是分析在发生崩溃时发送到系统控制台的 Oops 消息。一旦您掌握了细节,就可以将消息发送到 ksymoops 实用程序,它将试图将代码转换为指令并将堆栈值映射到内核符号。
    ※ 如:回溯线索中的地址,会通过ksymoops转化成名称可见的函数名。
    图2X光了格式化 Oops 消息过程:
   
 
    ksymoops需要几项内容:Oops 消息输出、来自正在运行的内核的 System.map 文件,还有 /proc/ksyms、vmlinux 和 /proc/modules。
关于如何使用 ksymoops,内核源代码 /usr/src/linux/Documentation/oops-tracing.txt 中或 ksymoops 手册页上有完整的说明可以参考。Ksymoops 反汇编代码部分,指出发生错误的指令,并显示一个跟踪部分表明代码如何被调用。
 
 2、kallsyms
    开发版2.5内核引入了kallsyms特性,它可以通过定义CONFIG_KALLSYMS编译选项启用。该选项可以载入内核镜像所对应的内存地址的符号名称(即函数名),所以内核可以打印解码之后的跟踪线索。相应,解码OOPS也不再需要System.map和ksymoops工具了。另外,
这样做,会使内核变大些,因为地址对应符号名称必须始终驻留在内核所在内存上。
    #cat /proc/kallsyms
     c0100240   T       _stext
     c0100240   t       run_init_process
     c0100240   T      stext
     c0100269   t       init
        …
 
五、内核调试配置选项
 在编译内核的时候,为了方便调试和测试代码,内核提供了许多配置选项。
 ※  启用选项例如:
   slab layer debugging(slab层调试选项)、high-memory debugging(高端内存调试选项)、I/O mapping debugging(I/O映射调试选项)、spin-lock debugging(自旋锁调试选项)、stack-overflow checking(栈溢出检查选项)和sleep-inside-spinlock checking(自旋锁内睡眠选项)等。
 
1、调试原子操作
 从内核2.5开发,为了检查各类由原子操作引发的问题,内核提供了极佳的工具。
 内核提供了一个原子操作计数器,它可以配置成,一旦在原子操作过程中,进城进入睡眠或者做了一些可能引起睡眠的操作,就打印警告信息并提供追踪线索。
 所以,包括在使用锁的时候调用schedule(),正使用锁的时候以阻塞方式请求分配内存等,各种潜在的bug都能够被探测到。
 下面这些选项可以最大限度地利用该特性:
 CONFIG_PREEMPT = y
 CONFIG_DEBUG_KERNEL = y
 CONFIG_KLLSYMS = y
 CONFIG_SPINLOCK_SLEEP = y
 
六、引发bug并打印信息
 1、一些内核调用可以用来方便标记bug,提供断言并输出信息。最常用的两个是BUG()BUG_ON()
 定义在中:

#ifndef HAVE_ARCH_BUG
#define BUG() do { 
    printk(
"BUG: failure at %s:%d/%s()! ", __FILE__, __LINE__, __FUNCTION__); 
    panic(
"BUG!");   /* 引发更严重的错误,不但打印错误消息,而且整个系统业会挂起 */
while (0)
#endif

#ifndef HAVE_ARCH_BUG_ON
    
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
#endif
  
当调用这两个宏的时候,它们会引发OOPS,导致栈的回溯和错误消息的打印
※ 可以把这两个调用当作断言使用,如:BUG_ON(bad_thing);
 
 2、dump_stack()
    有些时候,只需要在终端上打印一下栈的回溯信息来帮助你调试。这时可以使用dump_stack()。这个函数只在终端上打印寄存器上下文和函数的跟踪线索。
    if (!debug_check) {
        printk(KERN_DEBUG “provide some information…/n”);
        dump_stack();
    }
 备注:大部分内容引自《Linux内核设计实现 - 2版》

原文地址:http://blog.csdn.net/cugxueyu/article/details/1957740
阅读(1504) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~