C++如何读取和处理系统内核转储文件Dump【深度】
Linux 下的 /proc/kcore 不是真正的内核转储，别直接用 fread 读它
很多开发者一看到 /proc/kcore 这个路径，就下意识地把它当作现成的内核内存镜像，兴冲冲地尝试用 C++ 的 std::ifstream 或者 fopen 配合 fread 去直接加载。结果呢？要么是操作被拒绝（Operation not permitted），要么读出来的数据全是零。这可不是代码写错了，而是因为 /proc/kcore 本质上是一个由内核动态生成的虚拟文件。它只在进程调用 read() 系统调用时，才按需“制造”出内容。不仅如此，它的访问还受到 ptrace 权限和内核参数 kernel.kptr_restrict 的严格限制。普通用户进程默认是没有权限访问的。即便是 root 权限运行的程序，也可能因为内核编译时未启用 CONFIG_PROC_KCORE，或者系统设置了 vm.panic_on_oom=2 等配置，而导致这个文件根本不可读。
那么，真正可以被拿来分析的内核转储文件是什么呢？答案是像 kdump 这类崩溃转储工具生成的 vmlinux 和 vmcore 配对文件，或者是 qemu 通过 -dump-guest-core 参数输出的文件。C++ 程序想要处理它们，就必须依赖外部的解析逻辑，直接进行裸 I/O 操作是行不通的。
用 libdw + libelf 解析 vmlinux 符号表，否则地址无法映射
vmlinux 这个文件至关重要，它是包含了完整调试信息的内核镜像（ELF 格式）。没有它，你连像 sys_call_table 这样的关键数据结构在内存中的位置都无法知晓。在 C++ 程序中，你不能简单地用 std::ifstream 把它当作二进制文件读个头了事，必须使用专门的 ELF 解析库来定位其中的 .symtab（符号表）、.strtab（字符串表）以及 .debug_* 等调试段。
- 首先，程序需要链接
-ldw -lelf库。然后，使用elf_begin()函数打开vmlinux文件，再调用dwarf_begin_elf()来初始化 DWARF 调试信息。 dwarf_getfuncs()函数可以用来遍历所有的函数符号。但这里有个细节需要注意：像内联函数、或者被编译器优化掉的符号，是不会出现在这个列表里的。- 举个例子，要获取
sys_open函数的地址，流程大致是：dwarf_offdie(dwarfd, offset, &die)→dwarf_attr(&die, DW_AT_low_pc, &attr)→dwarf_formudata(&attr, &addr)。 - 还有一个常见陷阱：如果
vmlinux文件被strip过（这在发行版提供的内核中很常见），那么它的.symtab段就是空的。这时候，就必须退而求其次，配合使用System.map这个文本文件来进行地址查询。
vmcore 是 ELF core dump，但节区布局和用户态不同，libelf 会误判
vmcore 文件看起来也是个 ELF 文件（魔数开头是 7f 45 4c 46），但它的内涵大不相同。它的 PT_LOAD 程序头（Program Header）描述的是物理内存的页帧，而不是我们熟悉的虚拟地址。此外，它还包含一些特有的节区，比如 .mem、.note.linux。如果直接套用 elf_getphdrnum() 来遍历程序头，很可能会跳过一些关键的内存块。
正确的做法是先准确识别 vmcore 的类型：
- 可以先检查
elf_getehdr()得到的 ELF 头中的e_ident[EI_OSABI]字段：如果它是ELFOSABI_LINUX并且存在NT_PRSTATUS类型的 note，那么它可能是传统的 kdump 格式。 - 更可靠的方法是读取文件开头的 8 字节魔数（例如 64 位小端序是
0x45 0x4c 0x46 0x02 0x01 0x01 0x00 0x00），然后跳过 ELF 头，直接去解析struct vmcoreinfo_data结构（这个结构位于.note.vmcoreinfo节区中），从而获取页大小、架构偏移等关键元信息。 - 实际的内存数据存储在
PT_LOAD段所指向的p_offset文件偏移处。但是请注意，段头中的p_vaddr是物理地址，需要结合vmcoreinfo里提供的phys_base等信息进行校准转换。
不要手写内存遍历逻辑，用 crash 的 Python API 或 gcore 做预处理
用 C++ 直接解析 vmcore 很容易踩坑：页面对齐错误导致读取越界、压缩格式（如 gzip 或 lzma）没有先解压、稀疏内存块的跳过逻辑写错。对于生产环境，一个更稳妥的建议是绕过这些底层的裸解析工作：
- 使用
crash -s vmlinux vmcore --minimal -i 'rd /v sys_call_table'这样的命令，先通过成熟的 crash 工具抽取出关键结构体的地址，并将其输出为 JSON 等格式。然后，你的 C++ 程序只需要负责读取和解析这个 JSON 文件即可。 - 如果需要完整的内存视图，可以先用 root 权限执行
cp /proc/kcore /tmp/kcore.raw，再结合gcore -o /tmp/kernel.gcore $(pidof systemd)命令生成一个标准的 core 文件。之后，使用libbfd库来解析这个 core 文件（在处理 core 文件格式上，libbfd有时比libelf兼容性更好）。 - 对于实时性要求较高的场景（例如作为 eBPF 分析的辅助），可以考虑改用
libkdumpfile（这是 kdump 项目官方的库）。它封装了所有vmcore变种格式的解析逻辑，C++ 程序只需要调用kdump_file_open()和kdump_read_mem()这样的高层接口。
最后，也是最容易被忽略的一点：vmcore 中保存的所有指针值都是物理地址，而 vmlinux 符号表里给出的地址是编译时的虚拟地址。这两者之间差了一个 phys_to_virt 的映射偏移。这个偏移量并不直接记录在 ELF 文件里，必须从 vmcoreinfo 中的 phys_base 字段，结合内核启动日志里的 Memory: ...K/...K a vailable 等信息推算出来。如果少了这一步校准，那么之后所有对结构体字段的访问和解析，其地址基础都是错的。
