Linux怎么查看系统的内核符号表

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

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

这当然不是查不到，而是内核故意把地址掩码成了 0000000000000000。从 Linux 2.6.38 起，kptr_restrict 默认被设为 2，连 root 都被挡在门外，看不到真实地址。想临时放行？一条命令搞定：echo 0 > /proc/sys/kernel/kptr_restrict（当然需要 root 权限）。

• 如果希望永久生效，在 /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 的策略变化——这些因素叠加起来，让一次看似简单的符号查找，可能在不同机器、不同启动状态下给出完全不同的结果。