(ldd) ch04-调试技术(转载).txt

献给ARM初学者

       
      为了在/proc中创建一个健全的文件节点（可以read，write，seek等等），你需要定义f
      ile_operations结构和inode_operations结构，后者与前者有类似的作用和尺寸。创建
      这样一个i节点比起创建整个字符设备并没有什么不同。我们这里不讨论这个问题，如果
      你感兴趣，你可以在源码树fs/proc中获得进一步细节。
       
      与大多数/proc文件一样，如果文件节点仅仅用来读，创建它们是比较容易的，我将这里
      介绍这一技术。很不幸，这一技术只能在Linux 2.0及其后续版本中使用。
       
      这里是创建一个称为/proc/scullmem文件的scull代码，这个文件用来获取scull使用的
      内存信息。
       
      （代码）
       

       
      填写/proc文件非常容易。你的函数获取一个空闲页面填写数据；它将数据写进缓冲区并
      返回所写数据的长度。其他事情都由/proc文件系统处理。唯一的限制就是所写的数据不
      能超过PAGE_SIZE个字节（宏PAGE_SIZE定义在头文件<asm/page.h>中；它是与体系结构
      相关的，但你至少可以它有4KB大小）。
       
      如果你需要写多于一个页面的数据，你必须实现功能健全的文件。
       
      注意，如果一个正在读你的/proc文件的进程发出了若干read调用，每一个都获取新数据
      ，尽管只有少量数据被读取，你的驱动程序每次都要重写整个缓冲区。这些额外的工作
      会使系统性能下降，而且如果文件产生的数据与下一次的不同，以后的read调用要重新
      装配不相关的部分，这一会造成数据错位。事实上，由于每个使用C库的应用程序都大块
      地读取数据，性能并不是什么问题。然而，由于错位时有发生，它倒是一个值得考虑的
      问题。在获取数据后，库调用至少要调用1次read――只有当read返回0时才报告文件尾
      。如果驱动程序碰巧比前面产生了更多的数据，系统就返回到用户空间额外的字节并且
      与前面的数据块是错位的。我们将在第6章“时间流”的“任务队列”一节中涉及/proc/
      jiq*，那时我们还会遇到错位问题。
       
      cleanup_module中应该使用下面的语句注销/proc节点：
       
      （代码）
       
      传递给函数的参数是包含要撤销文件的目录名和文件的i节点号。由于i节点号是自动分

      传递给函数的参数是包含要撤销文件的目录名和文件的i节点号。由于i节点号是自动分
      配的，在编译时是无法知道的，必须从数据结构中读取。
       
      ioctl方法
      ioctl，下一章将详细讨论，是一个系统调用，它可以操做在文件描述符上；它接收一个
      “命令”号和（可选的）一个参数，通常这是一个指针。
       
      做为替代/proc文件系统的方法，你可以为调试实现若干ioctl命令。这些命令从驱动程
      序空间复制相关数据到进程空间，在进程空间里检查这些数据。
       
      只有使用ioctl获取信息比起/proc来要困难一些，因为你一个程序调用ioctl并显示结果
      。必须编写这样的程序，还要编译，保持与你测试的模块间的一致性等。
       
      不过有时候这是最好的获取信息的方法，因为它比起读/proc来要快得多。如果在数据写
      到屏幕前必须完成某些处理工作，以二进制获取数据要比读取文本文件有效得多。此外
      ，ioctl不限制返回数据的大小。
       
      ioctl方法的一个优点是，当调试关闭后调试命令仍然可以保留在驱动程序中。/proc文
      件对任何查看这个目录的人都是可见的，然而与/proc文件不同，未公开的ioctl命令通
      常都不会被注意到。此外，如果驱动程序有什么异常，它们仍然可以用来调试。唯一的
      缺点就是模块会稍微大一些。
       
      通过监视调试

      通过监视调试
      有时你遇到的问题并不特别糟，通过在用户空间运行应用程序来查看驱动程序与系统之
      间的交互过程可以帮助你捕捉到一些小问题，并可以验证驱动程序确实工作正常。例如
      ，看到scull的read实现如何处理不同数据量的read请求后，我对scull更有信心。
       
      有许多方法监视一个用户态程序的工作情况。你可以用调试器一步步跟踪它的函数，插
      入打印语句，或者用strace运行程序。在实际目的是查看内核代码时，最后一项技术非
      常有用。
       
      strace命令是一个功能非常强大的工具，它可以现实程序所调用的所有系统调用。它不
      仅可以显示调用，而且还能显示调用的参数，以符号方式显示返回值。当系统调用失败
      时，错误的符号值（如，ENOMEM）和对应的字串（Out of memory）同时显示。strace还
      有许多命令行选项；最常用的是-t，它用来显示调用发生的时间，-T，显示调用所花费
      的时间，以及-o，将输出重定向到一个文件中。默认情况下，strace将所有跟踪信息打
      印到stderr上。
       
      strace从内核接收信息。这意味着一个程序无论是否按调试方式编译（用gcc的-g选项）
      或是被去掉了符号信息都可以被跟踪。与调试器可以连接到一个运行进程并控制它类似
      ，你还可以跟踪一个已经运行的进程。
       
      跟踪信息通常用来生成错误报告报告给应用开发人员，但是对内核编程人员来说也一样
      非常有用。我们可以看到系统调用是如何执行驱动程序代码的；strace允许我们检查每
      一次调用输入输出的一致性。

      一次调用输入输出的一致性。
       
      例如，下面的屏幕输出给出了命令ls /dev > /dev/scull0的最后几行：
       
      （代码）
       
      很明显，在ls完成目标目录的检索后首次对write的调用中，它试图写4KB。很奇怪，只
      写了4000个字节，接着重试这一操作。然而，我们知道scull的write实现每次只写一个
      量子，我在这里看到了部分写。经过若干步骤之后，所有的东西都清空了，程序正常退
      出。
       
      另一个例子，让我们来读scull设备：
       
      （代码）
       
      正如所料，read每次只能读到4000个字节，但是数据总量是不变的。注意本例中重试工
      作是如何组织的，注意它与上面写跟踪的对比。wc专门为快速读数据进行了优化，它绕
      过了标准库，以便每次用一个系统调用读取更多的数据。你可以从跟踪的read行中看到w
      c每次要读16KB。
       
      Unix专家可以在strace的输出中找到很多有用信息。如果你被这些符号搞得满头雾水，
      我可以只看文件方法（open，read等等）是如何工作的。
       

       
      个人认为，跟踪工具在查明系统调用的运行时错误过程中最有用。通常应用或演示程序
      中的perror调用不足以用来调试，而且对于查明到底是什么样的参数触发了系统调用的
      错误也很有帮助。
       
      调试系统故障
      即便你用了所有监视和调试技术，有时候驱动程序中依然有错误，当这样的驱动程序执
      行会会造成系统故障。当这种情况发生时，获取足够多的信息来解决问题是至关重要的
      。
       
      注意，“故障”不意味着“panic”。Linux代码非常鲁棒，可以很好地响应大部分错误
      ：故障通常会导致当前进程的终止，但系统继续运行。如果在进程上下文之外发生故障
      ，或是组成系统的重要部件发生故障时，系统可能panic。但问题出在驱动程序时，通常
      只会导致产生故障的进程终止――即那个使用驱动程序的进程。唯一不可恢复的损失就
      是当进程被终止时，进程上下文分配的内存丢失了；例如，由驱动程序通过kmalloc分配
      的动态链表可能丢失。然而，由于内核会对尚是打开的设备调用close，你的驱动程序可
      以释放任何有open方法分配的资源。
       
      我们已经说过，当内核行为异常时会在控制台上显示一些有用的信息。下一节将解释如
      何解码和使用这些消息。尽管它们对于初学者来说相当晦涩，处理器的给出数据都是些
      很有意思的信息，通常无需额外测试就可以查明程序错误。
       
      Oops消息

      Oops消息
      大部分错误都是NULL指针引用或使用其他不正确的指针数值。这些错误通常会导致一个o
      ops消息。
       
      由处理器使用的地址都是“虚”地址，而且通过一个复杂的称为页表（见第13章“Mmap
      和DMA”中的“页表”一节）的结构映射为物理地址。当引用一个非法指针时，页面映射
      机制就不能将地址映射到物理地址，并且处理器向操作系统发出一个“页面失效”。如
      果地址确实是非法的，内核就无法从失效地址上“换页”；如果此时处理在超级用户太
      ，系统于是就产生一个“oops”。值得注意的是，在版本2.1中内核处理失效的方式有所
      变化，它可以处理在超级用户态的非法地址引用了。新实现将在第17章“最近发展”的
      “处理内核空间失效”中介绍。
       
      oops显示故障时的处理器状态，模块CPU寄存器内容，页描述符表的位置，以及其他似乎
      不能理解的信息。这些是由失效处理函数（arch/*/kernel/traps.c）中的printk语句产
      生的，而且象前面“Printk”一节介绍的那样进行分派。
       
      让我们看看这样一个消息。这里给出的是传统个人电脑（x86平台），运行Linux 2.0或
      更新版本的oops――版本1.2的输出稍有不同。
       
      （代码）
       
      上面的消息是在一个有意加入错误的失效模块上运行cat所至。fault.c崩溃如下代码：
       

       
      （代码）
       
      由于read从它的小缓冲区（faulty_buf）复制数据到用户空间，我们希望读一小块文件
      能够工作。然而，每次读出多于1KB的数据会跨越页面边界，如果访问了非法页面read就
      会失败。事实上，前面给出的oops是在请求一个4KB大小的read时发生的，这条消息在/v
      ar/log/messages（syslogd默认存放内核消息的文件）的oops消息前给出了：
       
      （代码）
       
      同样的cat命令却不能在Alpha上产生oops，这是因为从faulty_buf读取4KB字节没有超出