标签 调试 下的文章

根据定义,调试工具是那些那些使我们能够监测、控制和纠正其他程序的程序。我们为什么应该用调试工具呢? 在有些情况下,运行一些程序的时候我们会被卡住,我们需要明白究竟发生了什么。 例如,我们正在运行应用程序,它产生了一些错误消息。要修复这些错误,我们应该先找出为什么产生这些错误的消息和这些错误消息从哪里产生的。 一个应用程序可能突然挂起,我们必须了解其他什么进程同时在运行。我们可能还必须弄清楚某个进程挂起的时候在做什么。为了剖析这些细节, 我们需要调试工具的帮助。

(题图来自:axxomovies.org)

有几个Linux下的用户空间调试工具和技术,它们用来分析用户空间的问题相当有用。它们是:

  • 'print' 语句
  • 查询 (/proc, /sys 等)
  • 跟踪 (strace/ltrace)
  • Valgrind (memwatch)
  • GDB

让我们一个个地了解。

1.'print' 语句

这是一个基本的原始的调试问题的方法。 我们可以在程序中插入print语句来了解控制流和变量值。 虽然这是一个简单的技术, 但它有一些缺点。 程序需要进行编辑以添加'print'语句,然后必须重新编译,重新运行来获得输出。 如果要调试的程序相当大,这是一个耗时的方法。

2. 查询

在某些情况下,我们需要弄清楚在一个运行在内核中的进程的状态和内存映射。为了获得这些信息,我们不需要在内核中插入任何代码。 相反,可以用 /proc 文件系统。

/proc 是一个伪文件系统,系统一启动运行就收集着运行时系统的信息 (cpu信息, 内存容量等)。

output of 'ls /proc'

'ls /proc'的输出

正如你看到的, 系统中运行的每一个进程在/proc文件系统中有一个以进程id命名的项。每个进程的细节信息可以在进程id对应的目录下的文件中获得。

output of 'ls /proc/pid'

'ls /proc/pid'的输出

解释/proc文件系统内的所有条目超出了本文的范围。一些有用的列举如下:

  • /proc/cmdline -> 内核命令行
  • /proc/cpuinfo -> 关于处理器的品牌,型号信息等
  • /proc/filesystems -> 文件系统的内核支持的信息
  • /proc//cmdline -> 命令行参数传递到当前进程
  • /proc//mem -> 当前进程持有的内存
  • /proc//status -> 当前进程的状态

3. 跟踪

strace的和ltrace是两个在Linux中用来追踪程序的执行细节的跟踪工具。

strace:

strace拦截和记录系统调用及其接收的信号。对于用户,它显示了系统调用、传递给它们的参数和返回值。strace的可以附着到已在运行的进程或一个新的进程。它作为一个针对开发者和系统管理员的诊断、调试工具是很有用的。它也可以用来当做一个通过跟踪不同的程序调用来了解系统的工具。这个工具的好处是不需要源代码,程序也不需要重新编译。

使用strace的基本语法是:

strace 命令

strace有各种各样的参数。可以检查看strace的手册页来获得更多的细节。

strace的输出非常长,我们通常不会对显示的每一行都感兴趣。我们可以用'-e expr'选项来过滤不想要的数据。

用 '-p pid' 选项来绑到运行中的进程.

用'-o'选项,命令的输出可以被重定向到文件。

output of strace filtering only the open system call

strace过滤成只有系统调用的输出

ltrace:

ltrace跟踪和记录一个进程的动态(运行时)库的调用及其收到的信号。它也可以跟踪一个进程所作的系统调用。它的用法是类似与strace。

ltrace command

'-i' 选项在调用库时打印指令指针。

'-S' 选项被用来现实系统调用和库调用

所有可用的选项请参阅ltrace手册。

output of ltrace capturing 'strcmp' library call

ltrace捕捉'STRCMP'库调用的输出

4. Valgrind

Valgrind是一套调试和分析工具。它的一个被广泛使用的默认工具——'Memcheck'——可以拦截malloc(),new(),free()和delete()调用。换句话说,它在检测下面这些问题非常有用:

  • 内存泄露
  • 重释放
  • 访问越界
  • 使用未初始化的内存
  • 使用已经被释放的内存等。

它直接通过可执行文件运行。

Valgrind也有一些缺点,因为它增加了内存占用,会减慢你的程序。它有时会造成误报和漏报。它不能检测出静态分配的数组的访问越界问题。

为了使用它,首先请下载并安装在你的系统上。可以使用操作系统上的包管理器来安装。

使用命令行安装需要解压缩和解包下载的文件。

tar -xjvf valgring-x.y.z.tar.bz2 (where x.y.z is the version number you are trying to install)

进入新创建的目录(的valgrind-XYZ)内运行以下命令:

./configure
make
make install

让我们通过一个小程序(test.c)来理解valgrind怎么工作的:

#include <stdio.h>

void f(void)

{
int x = malloc(10 * sizeof(int));

x[10] = 0;
}

int main()
{
f();
return 0;
}

编译程序:

gcc -o test -g test.c

现在我们有一个可执行文件叫做'test'。我们现在可以用valgrind来检测内存错误:

valgrind –tool=memcheck –leak-check=yes test

这是valgrind呈现错误的输出:

output of valgrind showing heap block overrun and memory leak

valgrind显示堆溢出和内存泄漏的输出

正如我们在上面看到的消息,我们正在试图访问函数f未分配的内存以及分配尚未释放的内存。

5. GDB

GDB是来自自由软件基金会的调试器。它对定位和修复代码中的问题很有帮助。当被调试的程序运行时,它给用户控制权去执行各种动作, 比如:

  • 启动程序
  • 停在指定位置
  • 停在指定的条件
  • 检查所需信息
  • 改变程序中的数据 等。

你也可以将一个崩溃的程序coredump附着到GDB并分析故障的原因。

GDB提供很多选项来调试程序。 然而,我们将介绍一些重要的选择,来感受如何开始使用GDB。

如果你还没有安装GDB,可以在这里下载:GDB官方网站

编译程序:

为了用GDB调试程序,必须使用gcc的'-g'选项进行编译。这将以操作系统的本地格式产生调试信息,GDB利用这些信息来工作。

下面是一个简单的程序(example1.c)执行被零除用来显示GDB的用法:

#include
int divide()
{
int x=5, y=0;
return x / y;
}

int main()
{
divide();
}

An example showing usage of gdb

展示GDB用法的例子

调用 GDB:

通过在命令行中执行'gdb'来启动gdb:

invoking gdb

调用 gdb

调用后, 它将等待终端命令并执行,直到退出。

如果一个进程已经在运行,你需要将GDB连接到它上面,可以通过指定进程ID来实现。假设程序已经崩溃,要分析问题的原因,则用GDB分析core文件。

启动程序:

一旦你在GDB里面,使用'run'命令来启动程序进行调试。

给程序传参数:

使用'set args'给你的程序传参数,当程序下次运行时将获得该参数。'show args'将显示传递给程序的参数。

检查堆栈:

每当程序停止,任何人想明白的第一件事就是它为什么停止,以及怎么停在那里的。该信息被称为反向跟踪。由程序产生每个函数调用和局部变量,传递的参数,调用位置等信息一起存储在堆栈内的数据块种,被称为一帧。我们可以使用GDB来检查所有这些数据。 GDB从最底层的帧开始给这些帧编号。

  • bt: 打印整个堆栈的回溯
  • bt 打印n个帧的回溯
  • frame : 切换到指定的帧,并打印该帧
  • up : 上移'n'个帧
  • down : 下移'n'个帧 ( n默认是1)

检查数据:

程序的数据可以在里面GDB使用'print'命令进行检查。例如,如果'x'是调试程序内的变量,'print x'会打印x的值。

检查源码:

源码可以在GDB中打印。默认情况下,'list'命令会打印10行代码。

  • list : 列出'linenum'行周围的源码
  • list : 从'function'开始列出源码
  • disas : 显示该函数机器代码

停止和恢复程序:

使用GDB,我们可以在必要的地方设置断点,观察点等来停止程序。

  • break : 在'location'设置一个断点。当在程序执行到这里时断点将被击中,控制权被交给用户。
  • watch : 当'expr'被程序写入而且它的值发生变化时GDB将停止
  • catch : 当'event'发生时GDB停止
  • disable : 禁用指定断点
  • enable : 启用指定断点
  • delete : 删除 断点/观察点/捕获点。 如果没有传递参数默认操作是在所有的断点
  • step: 一步一步执行程序
  • continue: 继续执行程序,直到执行完毕

退出 GDB:

用'quit'命令还从GDB中退出。

GDB还有更多的可用选项。里面GDB使用help选项了解更多详情。

getting help within gdb

在GDB中获得帮助

总结

在这篇文章中,我们已经看到不同类型的Linux用户空间的调试工具。总结以上所有内容,如下是什么时候使用该什么的快速指南:

  • 基本调试,获得关键变量 - print 语句
  • 获取有关文件系统支持,可用内存,CPU,运行程序的内核状态等信息 - 查询 /proc 文件系统
  • 最初的问题诊断,系统调用或库调用的相关问题,了解程序流程 – strace / ltrace
  • 应用程序内存空间的问题 – valgrind
  • 检查应用程序运行时的行为,分析应用程序崩溃 – gdb

via: http://linoxide.com/linux-how-to/user-space-debugging-tools-linux/

作者:B N Poornima 译者:mtunique 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

没有调试器的情况下编写程序时最糟糕的状况是什么?编译时跪着祈祷不要出错?用血祭召唤恶魔帮你运行程序?或者在每一行代码间添加printf("test")语句来定位错误点?如你所知,编写程序时不使用调试器的话是不方便的。幸好,linux下调试还是很方便的。大多数人使用的IDE都集成了调试器,但 linux 最著名的调试器是命令行形式的C/C++调试器GDB。然而,与其他命令行工具一致,DGB需要一定的练习才能完全掌握。这里,我会告诉你GDB的基本情况及使用方法。

安装GDB

大多数的发行版仓库中都有GDB

Debian 或 Ubuntu

$ sudo apt-get install gdb

Arch Linux

$ sudo pacman -S gdb

Fedora,CentOS 或 RHEL:

$sudo yum install gdb

如果在仓库中找不到的话,可以从官网中下载

示例代码

当学习GDB时,最好有一份代码,动手试验。下列代码是我编写的简单例子,它可以很好的体现GDB的特性。将它拷贝下来并且进行实验——这是最好的方法。

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
    int i;
    int a=0, b=0, c=0;
    double d;
    for (i=0; i<100; i++)
    {
        a++;
        if (i>97)
            d = i / 2.0;
        b++;
    }
    return 0;
}

GDB的使用

首先最重要的,你需要使用编译器的 “-g“选项来编译程序,这样可执行程序才能通过GDB来运行。通过下列语句开始调试:

$ gdb -tui [可执行程序名]

使用”-tui“选项可以将代码显示在一个漂亮的交互式窗口内(所以被称为“文本用户界面 TUI”),在这个窗口内可以使用光标来操控,同时在下面的GDB shell中输入命令。

现在我们可以在程序的任何地方设置断点。你可以通过下列命令来为当前源文件的某一行设置断点。

break [行号]

或者为一个特定的函数设置断点:

break [函数名]

甚至可以设置条件断点

break [行号] if [条件]

例如,在我们的示例代码中,可以设置如下:

break 11 if i > 97

这样,程序循环97次之后停留在“a++”语句上。这样是非常方便的,避免了我们需要手动循环97次。

最后但也是很重要的是,我们可以设置一个“观察断点”,当这个被观察的变量发生变化时,程序会被停止。

watch [变量]

这里我们可以设置如下:

watch d

当d的值发生变化时程序会停止运行(例如,当i>97为真时)。

当设置断点后,使用"run"命令开始运行程序,或按如下所示:

r [程序的输入参数(如果有的话)]

gdb中,大多数的命令单词都可以简写为一个字母。

不出意外,程序会停留在11行。这里,我们可以做些有趣的事情。下列命令:

bt

回溯功能(backtrace)可以让我们知道程序如何到达这条语句的。

info locals

这条语句会显示所有的局部变量以及它们的值(你可以看到,我没有为d设置初始值,所以它现在的值是任意值)。

当然:

p [变量]

这个命令可以显示特定变量的值,而更进一步:

ptype [变量]

可以显示变量的类型。所以这里可以确定d是double型。

既然已经到这一步了,我么不妨这么做:

set var [变量] = [新的值]

这样会覆盖变量的值。不过需要注意,你不能创建一个新的变量或改变变量的类型。我们可以这样做:

set var a = 0

如其他优秀的调试器一样,我们可以单步调试:

step

使用如上命令,运行到下一条语句,有可能进入到一个函数里面。或者使用:

next

这可以直接运行下一条语句,而不进入子函数内部。

结束测试后,删除断点:

delete [行号]

从当前断点继续运行程序:

continue

退出GDB:

quit

总之,有了GDB,编译时不用祈祷上帝了,运行时不用血祭了,再也不用printf(“test“)了。当然,这里所讲的并不完整,而且GDB的功能远远不止于此。所以我强烈建议你自己更加深入的学习它。我现在感兴趣的是将GDB整合到Vim中。同时,这里有一个备忘录记录了GDB所有的命令行,以供查阅。

你对GDB有什么看法?你会将它与图形调试器对比吗,它有什么优势呢?对于将GDB集成到Vim有什么看法呢?将你的想法写到评论里。


via: http://xmodulo.com/gdb-command-line-debugger.html

作者:Adrien Brochard 译者:SPccman 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

在调试的时候,strace能帮助你追踪到一个程序所执行的系统调用。当你想知道程序和操作系统如何交互的时候,这是极其方便的,比如你想知道执行了哪些系统调用,并且以何种顺序执行。

这个简单而又强大的工具几乎在所有的Linux操作系统上可用,并且可被用来调试大量的程序。

命令用法

让我们看看strace命令如何追踪一个程序的执行情况。

最简单的形式,strace后面可以跟任何命令。它将列出许许多多的系统调用。一开始,我们并不能理解所有的输出,但是如果你正在寻找一些特殊的东西,那么你应该能从输出中发现它。

让我们来看看简单命令ls的系统调用跟踪情况。

raghu@raghu-Linoxide ~ $ strace ls

Stracing ls command

这是strace命令输出的前几行。其他输出被截去了。

Strace write system call (ls)

上面的输出部分展示了write系统调用,它把当前目录的列表输出到标准输出。

下面的图片展示了使用ls命令列出的目录内容(没有使用strace)。

raghu@raghu-Linoxide ~ $ ls

ls command output

选项1 寻找被程序读取的配置文件

Strace 的用法之一(除了调试某些问题以外)是你能找到被一个程序读取的配置文件。例如,

raghu@raghu-Linoxide ~ $ strace php 2>&1 | grep php.ini

Strace config file read by program

选项2 跟踪指定的系统调用

strace命令的-e选项仅仅被用来展示特定的系统调用(例如,open,write等等)

让我们跟踪一下cat命令的‘open’系统调用。

raghu@raghu-Linoxide ~ $ strace -e open cat dead.letter

Stracing specific system call (open here)

选项3 跟踪进程

strace不但能用在命令上,而且通过使用-p选项能用在运行的进程上。

raghu@raghu-Linoxide ~ $ sudo strace -p 1846

Strace a process

选项4 strace的统计概要

它包括系统调用的概要,执行时间,错误等等。使用-c选项能够以一种整洁的方式展示:

raghu@raghu-Linoxide ~ $ strace -c ls

Strace summary display

选项5 保存输出结果

通过使用-o选项可以把strace命令的输出结果保存到一个文件中。

raghu@raghu-Linoxide ~ $ sudo strace -o process_strace -p 3229

Strace a process

之所以以sudo来运行上面的命令,是为了防止用户ID与所查看进程的所有者ID不匹配的情况。

选项6 显示时间戳

使用-t选项,可以在每行的输出之前添加时间戳。

raghu@raghu-Linoxide ~ $ strace -t ls

Timestamp before each output line

选项7 更精细的时间戳

-tt选项可以展示微秒级别的时间戳。

raghu@raghu-Linoxide ~ $ strace -tt ls

Time - Microseconds

-ttt也可以向上面那样展示微秒级的时间戳,但是它并不是打印当前时间,而是显示自从epoch(译注:1970年1月1日00:00:00 UTC)以来的所经过的秒数。

raghu@raghu-Linoxide ~ $ strace -ttt ls

Seconds since epoch

选项8 相对时间

-r选项展示系统调用之间的相对时间戳。

raghu@raghu-Linoxide ~ $ strace -r ls

Relative Timestamp


via: http://linoxide.com/linux-command/linux-strace-command-examples/

作者:Raghu 译者:guodongxiaren 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Linux 内核补丁测试

你试过自己写内核补丁吗?本节介绍在把你的补丁包提交到 Linux 邮箱列表之前,需要做哪些操作。另外我们还会介绍如何把它发送出去。

写好代码后,编译它。把 make 过程产生的输出保存到文档中,查看新代码有没有警告信息。找到所有的警告信息,处理掉。当你的代码编译过程没有任何不正常的输出,安装这个内核,然后启动测试。如果启动正常,查看 dmesg 里面有没于错误,与老内核生成的 dmesg 日志做个比较。运行一些压力测试,请参考我们以前讲过的测试内容。如果这个补丁用于修复某个 bug,请确保真的已经修复了。如果真的修复了,请确保能通过系统测试。找出打你补丁的模块下面的回归测试工具,运行一下。如果补丁涉及到其他架构,你需要交叉编译然后测试一下。请通过下面的目录查找测试工具:

如果你对你的补丁测试结果感到很满意,你就可以提交补丁了。请确保提交 commit 的信息要描述得非常清楚。要让内核维护者和其他开发者看懂补丁所修改的内容,这一点非常重要。生成补丁后,执行 scripts/checkpatch.pl 脚本,找到 checkpatch 是产生的错误或警告(如果有的话),修复它们。重新生成补丁,直到补丁通过这个脚本的测试。重新测试这个补丁。将本补丁用于其他的内核源码上,保证不会有冲突产生。

现在你做好提交补丁的准备了。先运行 scriptst/get\_maintainer.pl 来确认你应该把补丁发给哪个内核维护者。注意不要以附件形式发送补丁,而是以纯文本形式粘贴在邮件里面。确保你的邮件客户端可以发送纯文本信息,你可以试试给自己发送一份补丁邮件来测试你的邮件客户端的功能。收到自己的邮件后,运行 checkpatch 命令并给自己的内核源码打上你的补丁。如果这两部都能通过,你就可以给 Linux 邮箱列表发送补丁了。使用 git send-email 命令是提交补丁最安全的方式,可以避免你的邮箱的兼容性问题。你的 .gitconfig 文件里面需要配置好有效的 smtp 服务器,详细操作参考 git 的帮助文档。

更多提交补丁的规矩,请参考下面的资料:

  • linux\_git/Documentation/applying-patches.txt
  • linux\_git/Documentation/SubmitChecklist
  • linux\_git/Documentation/SubmittingDrivers
  • linux\_git/Documentation/SubmittingPatches
  • linuxgit/Documentation/stablekernel\_rules.txt
  • linuxgit/Documentation/stableapi\_nonsense.txt

下面是一些内核测试教程的资料:

内核测试套件和项目

除我们讨论过的测试资源之外,这里还有很多测试项目值得介绍,包括开源的和厂家自己提供的。这些项目每一个都是针对特定领域的,比如嵌入式或者企业自己使用。我们简单过一下。

Linux 测试项目(LTP)测试套件是一系列工具的集合,用于测试内核的可靠性、健壮性和稳定性。你可以为这个项目添加自己的测试代码,并且 LTP 项目欢迎你贡献自己的代码。runltp 脚本默认情况下会测试下面的子系统:

  • 文件系统压力测试
  • 磁盘 IO 测试
  • 内存管理压力测试
  • IPC(进程间通信)测试
  • 调度器测试
  • 命令的功能性验证测试
  • 系统调用功能验证测试

LTP-DDT 是一个基于 LTP 的测试应用(LCTT:就是 LTP 的阉割版么),专注于测试嵌入式设备驱动。

Linux Driver Verification 这个项目的目标是提高 Linux 设备驱动的质量,它为设备驱动验证开发了集成环境平台,并且利用与时俱进的研究来增强验证工具的质量。

一致性测试

如果你有将某个 Unix 平台下的应用一直到另一个平台的经验,你就能理解 Linux Standard Base (LSB) 和 LSB 一致性测试套件的重要性了。LSB 是 Linux Foundation 工作组创建的用于降低支持不同 Linux 平台所需要的开销,方法就是通过降低不同 Linux 发行版之间的差别,保证应用在不同发行版之间的可移植性。前事不忘后事之师,Unix 世界的分歧在 Linux 世界一定要避免。这就是为什么你可以把一个 rpm 包转化成 deb 包后还能安装并正常运行的秘密。

静态分析工具

静态分析之所以会被称为“静态分析”,是因为这些工具只分析代码,并不执行它们。分析 Linux 内核代码的静态分析工具有很多,Sparse 是 Linus Torvalds 写的专门用于检查内核静态类型的工具。它是一个语义检查器,会为 C 语言的语义建立语义检析树,执行惰性类型评估。内核编译系统支持 sparse,并且为编译内核的命令提供开启 sparse 的选项。

为内核所有需要重新编译的 C 文件执行 sparse 语义检查:

make C=1 allmodconfig

为内核所有 C 文件(即使不需要重新编译)执行 sparse 语义检查:

make C=2 allmodconfig

Sparse 的资源:

Smatch 分析程序代码的逻辑错误。它可以检测到诸如“为一个没锁上的 spinlock 执行解锁”的逻辑错误。内核源码支持 smatch:

在 Linux 内核中运行 smatch:

make CHECK="~/path/to/smatch/smatch -p=kernel" C=1 bzImage modules | tee warns.txt

请参考下面的资料来获取和编译 smatch。需要注意的是 smatch 是个正在发展的项目,架构会不断变化。

那么我们该怎么处理 Sparse 和 Smatch 所发现的语义和逻辑上的错误呢?一些错误可以被分离为日常问题或模块问题,可以轻易被解决。但是有些语义错误涉及到全局,因为剪切粘贴了一些代码。在一些环境中,当一些接口函数被废弃不再使用,或者仅仅做了写微小的修改,你就需要大规模更新源码。这时候你需要 Coccinelle 来帮忙。,Coccinelle 使用 SmPL 语言(语义包语言)来为 C 代码提供匹配和转换代码的功能。Coccinelle 的从一开始就作为 Linux 的附属产品持续发展的。

举个例子:foo(int) 函数突然变成 foo(int, char *) 函数,多出了一个输入参数(可以把第二个参数置为 null)。所有调用 foo() 函数的代码都需要更新了,这可能是个悲摧的体力活。但是使用 Coccinelle 的话,这项工作瞬间变得轻松,脚本会帮你找到调用 foo(parameter1) 的代码,然后替换成 foo(parameter1, NULL)。做完这些后,所有调用这个函数的代码都可以运行一遍,验证下第二个参数为 NULL 是否能正常工作。关于 Coccinelle 的更多信息,以及在不同项目中(当然,也包括 Linux 内核这个项目)的使用方法,请参考项目主页:Cocinelle

参考文献

本文涵盖了很多方面,这里列出一些参考文档供读者做进一步研究。

鸣谢

感谢来自 Oracle 的 Khalid Aziz,审查校对并提供许多非常有价值的建议。感谢来自三星的 Mauro Chehab 和 Guy Martin,他们给了我多次反馈。感谢来自 Linux Foundation 的 Grey Kroah-Hartman 对本文的审阅。感谢来自三星的 Ibrahim Haddad,没有他的支持和鼓励,我可能还不会坐下来写出这篇文章。


作者:Shuah Khan

Shuah Khan 是三星公司开源组的高级 Linux 内核开发工程师。 她为 Linux 内核中的 IOMMU、DMA、电源管理、PCIe 贡献代码,同时维护内核,为内核提供补丁包。Shuah 有多年 Unix 内核开发经验。她也为 OpenHPI 和 LLDP 项目作贡献。


via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,5

译者:bazz2 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

仿真环境下进行 Linux 电源管理子系统测试

Linux 电源管理子系统在仿真环境下提供5种测试方式。这些方式仅仅在内核各层之间运行休眠的代码而不是真正的让系统进入休眠状态。有些平台不能挂起系统,比如说我们需要模拟飞机的飞行环境,这时候使用这种仿真环境就非常有用处了。

freezer - 测试停掉处理器:

echo freezer > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

devices - 测试停掉处理器以及挂起设备:

echo devices > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

platform - 测试停掉处理器、挂起设备以及平台全局控制方法(*)

echo platform > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

processors - 测试停掉处理器、挂起设备和平台全局控制方法(*),以及关闭未启动的 CPU。

echo processors > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

core - 测试停掉处理器、挂起设备和平台全局控制方法(*),关闭未启动的 CPU,以及挂起平台或系统的设备。注意:这个测试模式运行在 ACPI 系统。

echo core > /sys/power/pm_test
echo platform > /sys/power/disk
echo disk > /sys/power/state

Linux 电源管理子系统追踪事件

电源管理子系统在运行过程中支持多种追踪点和追踪事件。我将对如何使用这些追踪时间以及如何找到追踪信息作一个简单的介绍:

在运行时开启电源管理事件:

cd /sys/kernel/debug/tracing/events/power
echo 1 > cpu_frequency/enable
cat /sys/kernel/debug/tracing/set_event
less /sys/kernel/debug/tracing/trace

为内核启动的命令添加一个参数:

trace_event=cpu_frequency

更多信息查看 Documentation/power/basic-pm-debugging.txt 以及同目录下其他的文档。

git bisect 命令

git bisect 是一个非常有用非常强大的工具,用于将 git 上的一个 commit 分离出来。我简单过一遍它的用法。

下面是 git bisect 的用法:

git bisect start
git bisect bad   # 当前版本是坏的
git bisect good v3.14-rc6   # 上个版本是好的

一旦指定好好的版本和坏的版本,git bisect 就会开始把好坏两个版本之间的所有 commit 对半分,并将其中的一半提交 pull 下来。然后重新编译安装测试内核,并标记这个内核是好是坏。重复这个过程,知道某个你选好的 commit 被标记被好或者坏。我们可能需要测试多个内核版本,测到最后一个版本时,git bisect 会将一个 commit 标记为坏。下面的命令可以在 git bisect 分析过程中起到帮助作用:

查看 bisect 操作的过程:

git bisect log

重置 git bisect,标记错误时可以用到,保存 git log 的输出,重新操作上一次 bisect 的步骤:

git bisect reset

重放 git bisect 操作过程:

git bisect replay git_log_output

如果一个问题很清楚是在某个区域内,git bisect 命令可以定位到一个具体的内核源码树枝干上。举个例子,在调试一个镭龙显卡驱动的问题时,为 git bisect 指定 drivers/drm/radeon 参数,可以让 git bisect 只检索对 drivers/drm/radeon 里面的文件有修改的 commit。

让 git bisect 只检索内核树的某个枝干:

git bisect start drivers/drm/radeon

via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,4

译者:bazz2 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

自动测试工具

这里列出一些能满足不同需求的测试工具供你选择。本小节只是简单介绍个大概,并不提供详细操作指南。

AuToTest

AuToTest 是一个全自动测试框架,存在的主要目的就是测试 Linux 内核,当然也可以用来测试其他东西,比如测试一块新硬件是否能稳定工作。AuToTest 是开源软件,以 GPL 方式授权,运行于 server-client 架构(即 C/S 架构)。你可以通过配置 server 端来对运行了 client 端的系统执行初始化、运行与监测工作,也可以自己在目标系统上让 client 运行起来。另外你可以为这个测试框架添加测试用例,详情请参考AuToTest 白皮书

Linaro Automated Validation Architecture

LAVA 自动测试框架用于自动安装于运行测试。举个例子:你在 LAVA 里面只需运行几个命令就可以跑 LTP(LCTT:Linux Test Project,中文是 Linux 测试计划,SGI发起并由IBM负责维护,目的是为开源社区提供测试套件来验证Linux的可靠性、健壮性和稳定性)。通过 LAVA 命令可以自动为你安装 LTP 所需要的所有依赖包,下载源码、编译编码、将 LTP 安装到某个独立的地方,方便卸载 LTP 时能移除所有二进制文件。安装好 LTP 后,运行 LAVA 命令时添加 'ltp' 选项就可以运行 LTP 测试任务了,它会将测试结果以文件方式保存下来,文件名包含测试名称、时间戳。这些测试结果可以留着供以后参考。这是个发现软件退化(如果软件退化了的话)的好方法。下面列出 LAVA 配合 LTP 使用的一些命令:

显示 LAVA 支持的测试列表:

lava-test list-tests 

安装测试套件:

lava-test install ltp 

运行测试:

lava-test run ltp 

查看结果:

lava-test results show ltp-timestamp.0 

卸载测试套件:

lava-test uninstall ltp 

内核调试功能

Linux 内核本身包含很多调试功能,比如 kmemcheck 和 kmemleak。

kmemcheck

kmemcheck 是一个动态检查工具,可以检测出一些未被初始化的内存(LCTT:内核态使用这些内存可能会造成系统崩溃)并发出警告。它的功能与 Valgrind 类似,只是 Valgrind 运行在用户态,而 kmemchecke 运行在内核态。编译内核时加上 CONFIG\_KMEMCHECK 选项打开 kmemcheck 调试功能。你可以阅读 Documentation/kmemcheck.txt 来学习如何配置使用这个功能,以及如何看懂调试结果。

kmemleak

kmemleak 通过类似于垃圾收集器的功能来检测内核是否有内存泄漏问题。而 kmemleak 与垃圾收集器的不同之处在于前者不会释放孤儿目标(LCTT:不会再被使用的、应该被释放而没被释放的内存区域),而是将它们打印到 /sys/kernel/debug/kmemleak 文件中。用户态的 Valgrind 也有一个类似的功能,使用 --leak-check 选项可以检测并报错内存泄漏问题,但并不释放这个孤儿内存。编译内核时使用 CONFIG\_DEBUG\_KMEMLEAK 选项打开 kmemcleak 调试功能。阅读 Documentation/kmemleak.txt 来学习怎么使用这个工具并读懂调试结果。

内核调试接口

Linux 内核通过配置选项、调试用的 API、接口和框架来支持动态或静态的调试。我们现在就好好学习学习这些牛逼的功能,从静态编译选项开始讲。

调试配置选项:静态编译

大部分 Linux 内核以及内核模块都包含调试选项,你只要在编译内核或内核模块的时候添加这个静态调试选项,程序运行时后就会产生调试信息,并记录在 dmesg 缓存中。

调试的 API

调试 API 的一个很好的例子是 DMA-debug,用来调试驱动是否错误使用了 DMA 提供的 API。它会跟踪每个设备的映射关系,检测程序有没有试图为一些根本不存在的映射执行“取消映射”操作,检测代码建立 DMA 映射后可能产生的“映射丢失”的错误。内核配置选项 CONFIG\_HAVE\_DMA\_APT\_DEBUG 和 CONFIG\_DMA\_API\_DEBUG 可以为内核提供这个功能。其中,CONFIG\_DMA\_API\_DEBUG 选项启用后,内核调用 DMA 的 API 的同时也会调用 Debug-dma 接口。举例来说,当一个驱动调用 dma\_map\_page() 函数来映射一个 DMA 缓存时,dma\_map\_page() 会调用debug\_dma\_map\_page() 函数来跟踪这个缓存,直到驱动调用 dma\_unmap\_page() 来取消映射。详细内容请参考使用 DMA 调试 API 检测潜在的数据污染和内存泄漏问题

动态调试

动态调试功能就是你可以决定在程序运行过程中是否要 pr\_debug(), dev\_dbg(), print\_hex\_dump\_debug(), print\_hex\_dump\_bytes() 这些函数正常运行起来。什么意思?当程序运行过程中出现错误时,你可以指定程序打印有针对性的、详细的调试信息。这功能牛逼极了,我们不再需要为了添加调试代码定位一个问题,而重新编译安装内核。你可以指定 CONDIF\_DYNAMIC\_DEBUG 选项打开动态调试功能,然后通过 /sys/kernel/debug/dynamic\_debug/control 接口指定要打印哪些调试日志。下面分别列出代码级别和模块级别打印日志的操作方法:

让 kernel/power/suspend.c 源码第340行的 pr\_debug() 函数打印日志:

echo 'file suspend.c line 340 +p' > /sys/kernel/debug/dynamic_debug/control

让内核模块在加载过程中打开动态调试功能:

使用 modprobe 命令加在模块时加上 dyndbg='plmft' 选项。

让内核模块的动态调试功能在重启后依然有效:

编辑 /etc/modprobe.d/modname.conf 文件(没有这个文件就创建一个),添加 dyndbg='plmft' 选项。然而对于哪些通过 initramfs 加载的驱动来说,这个配置基本无效(LCTT:免费奉送点比较高级的知识哈。系统启动时,需要先让 initramfs 挂载一个虚拟的文件系统,然后再挂载启动盘上的真实文件系统。这个虚拟文件系统里面的文件是 initramfs 自己提供的,也就是说你在真实的文件系统下面配置了 /etc/modprobe.d/modname.conf 这个文件,initramfs 是压根不去理会的。站在内核驱动的角度看:如果内核驱动在 initramfs 过程中被加载到内核,这个驱动读取到的 /etc/modprobe.d/modname.conf 是 initramfs 提供的,而不是你编辑的那个。所以会有上述“写了配置文件后重启依然无效”的结论)。对于这种刁民,呃,刁驱动,我们需要修改 grub 配置文件,在 kernel 那一行添加 module.dyndbg='plmft' 参数,这样你的驱动就可以开机启动动态调试功能了。

想打印更详细的调试信息,可以使用 dynamic\_debug.verbose=1 选项。参考 Documentation/dynamic-debug-howto.txt 文件获取更多信息。

设置追踪点

到目前为止,我们介绍了多种动态和静态调试方法。静态调试选项和静态调试钩子函数(比如 DMA Debug API)需要的编译过程打开或关闭,导致了一个难过的事实:需要重新编译安装内核。而动态编译功能省去了“重新编译”这件麻烦事,但是也有不足的地方,就是调试代码引入了条件变量,用于判断是否打印调试信息。这种方法可以让你在程序运行时决定是否打印日志,但需要执行额外的判断过程。“追踪点”代码只会在程序运行过程中使用“追踪点”功能才会被触发。也就是说,“追踪点”代码与上述说的两种方法都不一样。当用不到它时,它不会运行(LCTT:动态调试的话,代码每次都需要查看下变量,然后判断是否需要打印日志;而“追踪点”貌似利用某种触发机制,不需要每次都去查看变量)。当你需要用到它时,程序的代码会把“追踪点”代码包含进去。它不会添加任何条件变量来增加系统的运行负担。

详细信息请参考布置追踪代码的小技巧

“追踪点”的原理

追踪点使用“跳跃标签”,这是一种使用分支跳转的编码修正(code modification)技术。

当关闭追踪点的时候,其伪代码看起来时这样的:

[ code1 ]
nop
back:
[ code2 ]
return;
tracepoint:
[ tracepoint code ]
jmp back;

当打开追踪点的时候,其伪代码看起来时这样的:(注意追踪点代码出现的位置)

[ code1 ]
jmp tracepoint
back:
[ code2 ]
return;
tracepoint:
[ tracepoint code ]
jmp back;

(LCTT:咳咳,解释解释上面两段伪代码吧,能看懂的大神请忽略这段注释。不使用追踪点时,代码运行过程是:code1->code2->return结束;使用追踪点时,代码运行过程是:code1->跳到tracepoint code执行调试代码->跳回code2->return结束。两段代码的唯一区别就是第二行,前者为 nop(不做任何操作),后者为 jmp tracepoint (跳到调试代码)。)

Linux 电源管理子系统的测试

使用静态调试、动态调试和追踪调试技术,我们来跑一下磁盘的电源管理测试。当系统被挂起时,内核会为磁盘创建一个休眠镜像,使磁盘进入休眠模式,当系统重新被唤醒时,内核又利用这个休眠镜像重新唤醒磁盘。

设置挂起设备与唤醒设备需要的时间:

echo 1 > /sys/power/pm_print_times

以 reboot 模式挂起磁盘:

echo reboot > /sys/power/disk
echo disk > /sys/power/state

以 shutdown 模式挂起磁盘 —— 与 reboot 模式一样,只是重新唤醒磁盘的话还需要电源提供。

echo shutdown > /sys/power/disk
echo disk > /sys/power/state

以 platform 模式挂起磁盘 —— 能测试更多内容,比如 BIOS 挂起和唤醒,会涉及到 ACPI 功能。我们推荐你使用这种方式,把 BIOS 也拉下水陪你玩挂起和唤醒游戏。

echo platform > /sys/power/disk
echo disk > /sys/power/state

via:http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,3

译者:bazz2 校对:校对者ID

本文由 LCTT 原创翻译,Linux中国 荣誉推出