3. 内核符号表与调试信息

内核内存Dump分析的核心挑战在于：如何将二进制内存地址映射回有意义的函数名、变量名和数据结构。没有符号表和调试信息，Crash工具看到的只是一堆十六进制数字。本章深入剖析内核符号解析的四个层次：System.map静态符号表、Kallsyms运行时机制、DWARF调试信息格式以及debuginfo包的获取方法。

3.1 内核符号表基础：vmlinux与System.map

vmlinux是编译生成的未压缩内核ELF文件，包含完整的代码段、数据段和符号表。System.map是从vmlinux中提取的文本格式符号列表，每行记录一个符号的地址、类型和名称。

System.map的典型行格式：

ffffffff81000000 T _text
ffffffff81000100 t start_kernel
ffffffff81234567 D init_task
ffffffff81a00000 A _end
ffffffffc0000000 T ext4_init_module  [ext4]

符号类型说明：T/t=代码段（全局/局部），D/d=数据段，A=绝对值，B/b=BSS段，R/r=只读数据。

3.2 Kallsyms机制：运行时符号解析

Kallsyms是内核内置的运行时符号表子系统，它将所有内核符号（包括动态模块）的地址-名称映射编译进内核映像，支持通过/proc/kallsyms查询。

Kallsyms的符号压缩机制：内核符号名通常很长（如__do_softirq+0x0/0x100），Kallsyms使用基于token的压缩算法将存储空间减少约50%。Crash工具在加载vmlinux时会自动解压并重建完整符号表。

3.3 DWARF调试信息：结构体布局与变量类型

仅有符号表只能知道地址→名称的映射，无法获取结构体成员偏移、变量类型、局部变量位置等类型信息。DWARF（Debugging With Attributed Record Formats）是ELF文件中携带的标准化调试信息格式，Crash工具依赖它解析复杂数据结构。

DWARF调试信息示例（使用readelf -w查看）：

<1><1a2>: DW_TAG_structure_type
    DW_AT_name      : (strp) "task_struct"
    DW_AT_byte_size : (data2) 9408
    <2><1b0>:   DW_TAG_member
        DW_AT_name    : (strp) "state"
        DW_AT_type    : (ref4) <0x123>  // volatile long
        DW_AT_data_member_location: (data1) 0
    <2><1c5>:   DW_TAG_member
        DW_AT_name    : (strp) "stack"
        DW_AT_type    : (ref4) <0x456>  // void *
        DW_AT_data_member_location: (data1) 8
    <2><1da>:   DW_TAG_member
        DW_AT_name    : (strp) "pid"
        DW_AT_type    : (ref4) <0x789>  // pid_t
        DW_AT_data_member_location: (data1) 1176

Crash工具通过struct task_struct命令输出时，会解析DWARF信息并显示每个成员的偏移和类型：

crash> struct task_struct -o
struct task_struct {
    [0] volatile long state;
    [8] void *stack;
    [16] atomic_t usage;
    [24] unsigned int flags;
    [32] unsigned int ptrace;
    ...
    [1176] pid_t pid;
    [1180] pid_t tgid;
    ...
}
SIZE: 9408

3.4 debuginfo包的获取与安装

主流Linux发行版将调试信息分离为独立的debuginfo包，避免生产环境安装过大的调试文件。以下是各发行版的获取方法：

Kdump场景下的debuginfo使用流程：

1. 收集信息：记录kdump触发时的内核版本 uname -r
2. 获取匹配包：在分析机上安装完全相同版本的debuginfo包
3. 验证一致性：使用crash vmlinux vmcore加载，检查mod命令输出的模块列表是否与dump时一致
4. 符号验证：执行sym -l检查符号总数，对比cat /proc/kallsyms | wc -l（需在相同内核上）

3.5 实战：验证调试信息完整性

加载vmlinux后，通过以下Crash命令快速验证调试信息是否完整：

# 检查符号总数（正常内核约5万~20万个符号）
crash> sym -l | wc -l
152345

# 检查结构体解析能力
crash> struct task_struct -o | head -5
struct task_struct {
    [0] volatile long state;
    [8] void *stack;
    [16] atomic_t usage;
    ...

# 检查模块符号
crash> mod -S
     MODULE       NAME            SIZE  OBJECT FILE
ffffffffc0000000  ext4          123456  /usr/lib/debug/lib/modules/.../ext4.ko.debug

# 检查栈回溯能力
crash> bt -l
PID: 12345  TASK: ffff88003e2c0000  CPU: 2   COMMAND: "sshd"
 #0 [ffff88003e2c3e50] __schedule at /build/linux-xxx/kernel/sched/core.c:3456
 #1 [ffff88003e2c3ea0] schedule at /build/linux-xxx/kernel/sched/core.c:3521
 ...

如果struct命令输出"struct: invalid data structure reference: task_struct"，说明vmlinux缺少DWARF调试信息，需要安装debuginfo包或使用--no-debug模式（功能受限）。