27、Linux内核与嵌入式应用调试全解析

Linux内核与嵌入式应用调试全解析

在Linux开发过程中，调试是确保系统稳定运行和应用程序正常工作的关键环节。本文将深入探讨Linux内核调试以及嵌入式Linux应用调试的相关技术和方法。

1. Linux内核调试要点

Linux内核调试具有诸多复杂性，特别是在交叉开发环境中。以下是一些关键的调试技术和工具：
- KGDB ：这是一个非常有用的内核级gdb存根，它允许在Linux内核和设备驱动程序内部进行直接的符号源级调试。KGDB使用gdb远程协议与基于主机的交叉gdb进行通信。例如，在调试内核代码时，我们可以利用KGDB在特定位置设置断点，观察程序的执行流程。
- 理解编译器优化 ：编译器优化有时会导致调试器行为看似奇怪。了解并尽量减少编译器优化，有助于我们理解在调试经过编译器优化的代码时遇到的问题。例如，在某些情况下，编译器可能会对代码进行重排或优化，导致调试时变量的显示和预期不一致。
- gdb用户自定义命令 ：gdb支持用户自定义命令，这对于自动化繁琐的调试任务非常有用，比如遍历内核链表和访问复杂变量。我们可以根据自己的需求编写自定义命令，提高调试效率。
- 内核可加载模块调试 ：对于内核可加载模块的源级调试，我们可以在module.c文件中调用module->init()的地方设置断点，来调试模块的初始化例程。
- printk和Magic SysReq键 ：printk是内核中常用的打印函数，通过查看printk输出的日志信息，我们可以定位内核开发和调试过程中的问题。Magic SysReq键则提供了一种在紧急情况下与内核交互的方式。
- 硬件辅助调试 ：通过JTAG探针进行硬件辅助调试，可以调试驻留在Flash或ROM中的代码，在其他调试方法繁琐或无法使用的情况下，这种方法非常有效。
- 启用CONFIG_SERIAL_TEXT_DEBUG ：在支持该功能的架构上启用CONFIG_SERIAL_TEXT_DEBUG，是调试新内核端口的强大工具。
- 检查printk log_buf ：检查printk的日志缓冲区通常可以找出启动时无声内核崩溃的原因。
- KGDB处理内核恐慌 ：当内核发生恐慌时，KGDB会将控制权传递给gdb，使我们能够检查回溯信息并找出内核恐慌的原因。

2. 嵌入式Linux应用调试

嵌入式Linux应用调试有其独特的挑战，因为嵌入式目标设备的资源通常有限。以下是一些常用的调试方法和工具：

2.1 目标调试

在目标设备上调试Linux应用代码时，我们可以使用一些小型工具，如strace、ltrace、dmalloc、ps和top等。这些工具可以直接在目标硬件上运行，帮助我们观察和分析进程的行为。
- strace和ltrace ：用于观察和表征进程的行为，通常可以隔离问题。例如，strace可以跟踪系统调用，帮助我们了解程序与操作系统的交互过程。
- dmalloc ：有助于隔离内存泄漏并分析内存使用情况。通过dmalloc，我们可以检测程序中是否存在内存泄漏问题，并找出泄漏的位置。
- ps和top ：用于检查进程的状态。ps可以列出当前运行的进程信息，top则可以实时显示系统中各个进程的资源使用情况。

然而，由于嵌入式目标设备的资源限制，我们可能无法在目标设备上运行一些开发工具。这时，交叉开发工具和NFS根挂载环境就派上用场了。许多工具，特别是GDB，被设计为在开发主机上执行，同时对远程目标设备上的代码进行调试。GDB可以用于交互式调试目标代码，也可以对应用程序崩溃生成的核心文件进行事后分析。

2.2 远程（交叉）调试

交叉开发工具主要是为了克服嵌入式平台的资源限制而开发的。在进行交叉调试时，我们可以将编译带有符号调试信息的ELF文件放在开发主机上，而在目标设备上使用剥离了不必要调试信息的二进制文件，以节省目标设备的存储空间。

以下是一个具体的操作步骤：
1. 查看ELF文件的调试信息 ：使用readelf工具查看编译带有符号调试信息的ELF文件的调试信息。例如，对于一个为ARM架构编译的小型Web服务器应用程序，我们可以使用以下命令查看其调试信息：

$ xscale_be-readelf -S websdemo

输出结果如下：

There are 39 section headers, starting at offset 0x3dfd0:
Section Headers:
[Nr] Name              Type        Addr     Off    Size   ES Flg Lk Inf Al
[ 0]                   NULL        00000000 000000 000000 00      0  0  0
[ 1] .interp           PROGBITS    00008154 000154 000013 00   A  0  0  1
[ 2] .note.ABI-tag     NOTE        00008168 000168 000020 00   A  0  0  4
...

从输出中可以看到，文件中有很多包含调试信息的部分，还有一个.comment部分包含了超过2KB的对应用程序运行不必要的信息。
2. 剥离目标应用程序 ：使用strip工具剥离目标应用程序的符号调试信息和.comment部分。例如：

$ xscale_be-strip -s -R .comment -o websdemo-stripped websdemo

执行上述命令后，我们可以比较剥离前后文件的大小：

$ ls -l websdemo*
-rwxrwxr-x  1 chris chris 283491 Apr  9 09:19 websdemo
-rwxrwxr-x  1 chris chris 123156 Apr  9 09:21 websdemo-stripped

可以看到，剥离后的二进制文件大小不到原始文件的一半。
3. 使用gdbserver进行远程调试 ：gdbserver是一个运行在目标设备上的小程序，它允许我们从开发工作站对目标设备上的进程进行远程调试。具体步骤如下：
- 在目标设备上启动gdbserver：

$ gdbserver localhost:2001 websdemo-stripped

输出结果如下：

Process websdemo-stripped created; pid = 197
Listening on port 2001

- 在开发工作站上启动GDB并连接到目标设备：

$ xscale_be-gdb -q websdemo
(gdb) target remote 192.168.1.141:2001

连接成功后，我们可以进行后续的调试操作，如设置断点、查看变量等。

需要注意的是，在开发主机上使用的GDB必须是配置为交叉调试器的版本，它能够理解为其他架构编译的二进制可执行文件。例如，我们不能使用典型的Red Hat Linux安装中的本地GDB来调试PowerPC目标设备，而必须使用为特定主机和目标组合配置的GDB。

下面是一个简单的mermaid流程图，展示了远程调试的基本流程：

graph LR
    A[开发主机] -->|启动GDB| B[GDB]
    C[目标设备] -->|启动gdbserver| D[gdbserver]
    B -->|连接请求| D
    D -->|接受连接| B
    B -->|调试命令| D
    D -->|执行结果| B

3. 共享库调试

在调试使用共享库的应用程序时，我们需要解决共享库和调试符号的复杂性问题。除非应用程序是静态链接的可执行文件，否则应用程序中的许多符号会引用应用程序外部的代码。例如，标准C库例程（如fopen、printf、malloc和memcpy）以及应用程序特定的函数都可能调用库函数。

为了让GDB能够访问这些库的符号，我们需要满足两个条件：
- 拥有可用的库的调试版本。
- 让GDB知道在哪里可以找到这些库。

如果没有可用的库的调试版本，我们仍然可以调试应用程序，但在调试调用库例程的代码时，将没有调试信息可用。

以下是一个在GDB中调试共享库的示例：

$ xscale_be-gdb -q websdemo
(gdb) target remote 192.168.1.141:2001

连接成功后，GDB可能会输出类似以下的信息：

Remote debugging using 192.168.1.141:2001
0x40000790 in ?? ()

这里出现问号是因为这是Linux动态加载器（ld-x.y.z.so），并且在当前平台上没有该共享库的调试符号。我们可以通过查看/proc文件系统中的maps条目来确认这一点。

GDB可以提醒我们共享库事件，这对于理解应用程序的行为或Linux加载器的行为，以及在共享库例程中设置断点非常有用。例如：

(gdb) i shared       # 显示当前加载的共享库
No shared libraries loaded at this time.
(gdb) b main         # 在main函数处设置断点
Breakpoint 1 at 0x12b80: file main.c, line 72.
(gdb) c              # 继续执行
Continuing.
Breakpoint 1, main (argc=0x1, argv=0xbec7fdc4) at main.c:72
72               int localvar = 9;
(gdb) i shared       # 再次显示当前加载的共享库
From        To          Syms Read   Shared Object Library
0x40033300  0x4010260c  Yes         /opt/mvl/.../lib/tls/libc.so.6
0x40000790  0x400133fc  Yes         /opt/mvl/.../lib/ld-linux.so.3
(gdb) set stop-on-solib-events 1    # 设置在共享库事件时停止
(gdb) c              # 继续执行
Continuing.
Stopped due to shared library event
(gdb) i shared       # 再次显示当前加载的共享库
From        To          Syms Read   Shared Object Library
0x40033300  0x4010260c  Yes         /opt/mvl/.../lib/tls/libc.so.6
0x40000790  0x400133fc  Yes         /opt/mvl/.../lib/ld-linux.so.3
0x4012bad8  0x40132104  Yes         /opt/mvl/.../libnss_files.so.2

我们可以使用ldd命令查看应用程序依赖的共享库。在目标设备上执行ldd命令，会显示共享库的绝对路径：

root@coyote:/workspace# ldd websdemo
         libc.so.6 => /lib/tls/libc.so.6 (0x40020000)
         /lib/ld-linux.so.3    (0x40000000)

但在开发主机上运行的GDB不能使用这些路径来查找库，因为主机和目标设备的架构可能不同。我们需要使用交叉版本的ldd来查看工具链预配置的库路径：

$ xscale_be-ldd    websdemo
   libc.so.6 => /opt/mvl/.../xscale_be/target/lib/libc.so.6 (0xdead1000)
   ld-linux.so.3 => /opt/mvl/.../xscale_be/target/lib/ld-linux.so.3 (0xdead2000)

GDB提供了show solib-absolute-prefix命令来显示其配置的查找共享库的前缀路径，我们也可以使用set solib-absolute-prefix和set solib-search-path命令来设置或更改GDB搜索共享库的位置。

下面是一个表格，总结了共享库调试的相关要点：
| 要点 | 说明 |
| ---- | ---- |
| 调试符号要求 | 拥有可用的库的调试版本，并让GDB知道库的位置 |
| ldd命令 | 目标设备上的ldd显示绝对路径，交叉版本的ldd显示工具链预配置的路径 |
| GDB命令 | show solib-absolute-prefix查看前缀路径，set solib-absolute-prefix和set solib-search-path设置搜索路径 |

通过以上方法，我们可以更有效地调试Linux内核和嵌入式应用程序，解决开发过程中遇到的各种问题，确保系统的稳定性和可靠性。

Linux内核与嵌入式应用调试全解析

4. 调试技巧总结

在进行Linux内核和嵌入式应用调试时，我们可以总结一些实用的技巧，以提高调试效率和准确性。以下是一些关键技巧的总结：

4.1 内核调试技巧

• 合理利用工具组合 ：结合KGDB、printk、硬件辅助调试等多种工具，从不同角度对内核进行调试。例如，在使用KGDB设置断点进行详细调试的同时，通过printk输出关键信息，快速定位大致问题范围。
• 关注编译器优化影响 ：在调试过程中，注意编译器优化可能带来的问题。如果遇到调试器行为异常，可以尝试减少编译器优化选项，以便更清晰地观察代码执行流程。
• 模块化调试 ：对于内核可加载模块，采用模块化调试的方法，在模块初始化和关键函数处设置断点，逐步排查问题。

4.2 嵌入式应用调试技巧

• 资源优化使用 ：由于嵌入式设备资源有限，合理使用交叉开发工具和NFS根挂载环境，将大部分调试工作放在开发主机上进行，减少目标设备的资源占用。
• 共享库管理 ：在调试使用共享库的应用程序时，确保拥有调试版本的共享库，并正确配置GDB查找共享库的路径。可以通过交叉版本的ldd命令查看工具链预配置的路径，避免因路径问题导致调试信息缺失。
• 利用GDB自定义命令 ：根据调试需求，编写GDB自定义命令，自动化一些繁琐的调试任务，如遍历链表、查看复杂数据结构等。

以下是一个mermaid流程图，展示了综合调试的基本思路：

graph LR
    A[开始调试] -->|选择调试类型| B{内核调试还是应用调试}
    B -->|内核调试| C[使用KGDB、printk等工具]
    C -->|设置断点、查看日志| D[定位问题]
    B -->|应用调试| E[使用交叉开发工具]
    E -->|处理共享库问题| F[确保调试符号可用]
    F -->|设置GDB搜索路径| G[开始调试应用]
    D -->|解决问题| H[调试结束]
    G -->|解决问题| H

5. 常见问题及解决方法

在调试过程中，我们可能会遇到一些常见问题，以下是这些问题的分析及解决方法：

5.1 内核调试常见问题

问题	现象	解决方法
内核恐慌	系统崩溃，无法正常运行	使用KGDB在发生恐慌时获取回溯信息，检查关键代码和硬件驱动
无声内核崩溃	启动时系统无响应	检查printk log_buf，查看是否有错误信息输出
调试信息异常	调试器显示的信息与预期不符	减少编译器优化选项，重新编译内核

5.2 嵌入式应用调试常见问题

问题	现象	解决方法
共享库加载失败	GDB显示找不到共享库符号	确保拥有调试版本的共享库，使用交叉版本的ldd查看路径，使用GDB命令设置正确的搜索路径
目标设备资源不足	无法在目标设备上运行开发工具	使用交叉开发工具，将调试工作转移到开发主机上
GDB连接失败	开发主机上的GDB无法连接到目标设备的gdbserver	检查网络连接、IP地址和端口号，确保使用的是配置为交叉调试器的GDB版本

6. 实际案例分析

为了更好地理解上述调试方法和技巧，我们来看一个实际的案例。假设我们有一个嵌入式Web服务器应用程序，在运行过程中出现了崩溃的问题。

6.1 问题发现

在目标设备上运行Web服务器应用程序时，程序突然崩溃，没有明显的错误信息输出。

6.2 调试过程

1. 初步排查 ：使用strace和ltrace工具观察进程行为，发现程序在调用某个共享库函数时崩溃。

$ strace -o strace.log websdemo
$ ltrace -o ltrace.log websdemo

2. 共享库检查 ：使用ldd命令查看应用程序依赖的共享库，发现某个共享库的调试信息缺失。

root@coyote:/workspace# ldd websdemo

3. 获取调试版本的共享库 ：从开发主机的工具链中获取该共享库的调试版本，并确保GDB能够找到它。

$ xscale_be-ldd    websdemo
(gdb) set solib-search-path /opt/mvl/.../xscale_be/target/lib

4. 使用gdbserver进行远程调试 ：在目标设备上启动gdbserver，在开发主机上启动GDB并连接到目标设备。

# 目标设备
$ gdbserver localhost:2001 websdemo-stripped
# 开发主机
$ xscale_be-gdb -q websdemo
(gdb) target remote 192.168.1.141:2001

5. 设置断点调试 ：在调用共享库函数的位置设置断点，逐步执行代码，找出问题所在。

(gdb) b function_name
(gdb) c

6.3 问题解决

通过上述调试过程，我们发现共享库中的一个函数存在内存访问越界的问题。修复该问题后，重新编译并运行应用程序，问题得到解决。

7. 总结

调试是Linux内核和嵌入式应用开发过程中不可或缺的环节。通过掌握各种调试技术和工具，如KGDB、GDB、printk等，以及合理运用调试技巧和解决常见问题的方法，我们可以更高效地定位和解决开发过程中遇到的问题。同时，通过实际案例的分析，我们可以更好地理解调试的实际应用，提高自己的调试能力，确保系统的稳定性和可靠性。在未来的开发中，不断积累调试经验，将有助于我们更快地解决各种复杂的问题。