如何查看Linux内核符号表

调试内核时，最常用的操作之一就是查看符号表，但很多人一上来就撞墙——cat /proc/kallsyms 打出来全是 0。别急着怀疑系统坏了，这是内核主动跟你玩起了捉迷藏。

为什么 cat /proc/kallsyms 输出全是 0？

这并非查不到，而是内核故意将地址掩码为 0000000000000000。自 Linux 2.6.38 起，kptr_restrict 默认设为 2，连 root 用户也无法查看真实地址。如需临时放行，可使用以下命令（需 root 权限）：echo 0 > /proc/sys/kernel/kptr_restrict。

• 如需永久生效，可在 /etc/sysctl.conf 中添加 kernel.kptr_restrict = 0，然后执行 sysctl -p 加载配置。
• 注意 kptr_restrict=1 的情况：此时只有具备 CAP_SYSLOG 能力的进程（如 syslogd 或以 root 启动的某些调试工具）才能看到真实地址。普通用户态程序仍然无法获取。

使用 grep 查询函数或变量时总漏匹配？

许多人直接使用 grep ioctl /proc/kallsyms，结果什么也没找到——原因在于符号名常带有下划线前缀，例如 __do_sys_ioctl，直接搜索 ioctl 自然容易遗漏。此外，大小写和符号类型字段也可能干扰结果。

• 查询函数时，建议用 " T " 或 " t " 过滤文本段：grep " T " /proc/kallsyms | grep -i ioctl
• 查询全局变量则用 " D " 或 " d " 过滤数据段：grep " D " /proc/kallsyms | grep jiffies
• 如需忽略前缀差异，可使用正则表达式：grep -E "(do_sys|__do_sys)_ioctl" /proc/kallsyms
• 精简输出的常用组合：grep -i "printk" /proc/kallsyms | awk '{print $1, $3}' 即可仅显示地址和符号名。

System.map 和 /proc/kallsyms 究竟该用哪个？

二者并非替代关系，而是静态快照与动态视图的区别。选错了，获取的地址可能完全无效，或无法找到模块中的符号。

• /proc/kallsyms 包含所有已加载模块的符号，实时更新，但受 kptr_restrict 控制，权限不足时无法查看。
• System.map 是编译时生成的静态文件（通常位于 /boot/System.map-$(uname -r)），不含模块信息，地址固定，但不反映 KASLR 实际加载偏移。
• 调试 panic 日志中的地址时，需确认当时是否启用了 KASLR。若已启用，System.map 的地址很可能无法对应，必须使用运行中的 /proc/kallsyms 才能还原。
• 模块开发中定位本模块符号时，/proc/kallsyms 更可靠；若仅分析离线 vmlinux 文件，直接使用 nm vmlinux 即可。

kallsyms_lookup_name() 在模块中调用失败？

该函数自内核 5.7 起不再导出，5.12 后彻底移出导出列表。部分发行版（如 RHEL 8.8+）甚至默认禁用该接口。因此，不建议直接依赖此调用。

• 如仍尝试调用，调用前必须检查返回值：unsigned long addr = kallsyms_lookup_name("unexported_func"); if (!addr) return -EINVAL;
• 需包含头文件 #include （注意较新内核可能不暴露该函数）。
• 即使编译通过，运行时也可能返回 NULL。这不代表符号不存在，而是内核配置禁用了接口，或未启用 CONFIG_KALLSYMS。
• 替代方案：改用 /proc/kallsyms 解析加用户态预读，或依赖 debugfs 下的 kallsyms 接口（如可用）。

本质上，真正的难点不在于“怎么查”，而在于查到的地址是否可用。KASLR 随机化、模块热插拔、kptr_restrict 级别以及内核版本对 kallsyms_lookup_name 的策略变化——这些因素叠加起来，使得一次看似简单的符号查找，在不同机器、不同启动状态下可能产生完全不同的结果。