因为内核默认启用kptr_restrict=2，会将所有非导出符号地址强制替换为0x0000000000000000，即使root权限也无法绕过此主动隐藏机制，需临时执行echo 0 > /proc/sys/kernel/kptr_restrict或永久配置kernel.kptr_restrict=0方可读取真实地址。
为什么直接读 /proc/kallsyms 大概率失败
Linux 内核从 2.6.38 开始默认启用 kptr_restrict，值为 2 时会把所有非导出符号（包括大部分函数地址）替换成 0x0000000000000000，即使你有 root 权限也看不到真实地址。这不是权限问题，是内核主动隐藏——cat /proc/kallsyms | head -n3 看到的全是 0000000000000000 就是这个原因。
常见误操作：用 fopen("/proc/kallsyms", "r") 读完发现全零，以为代码写错了。其实 C++ 读文件逻辑完全正确，错在没调 sysctl 或改内核参数。
-
echo 0 | sudo tee /proc/sys/kernel/kptr_restrict可临时放开（需 root） - 永久生效要写入
/etc/sysctl.conf：添加kernel.kptr_restrict = 0 - 注意：生产环境慎用，暴露内核地址可能削弱 KASLR 防御效果
用 C++ 安全解析 /proc/kallsyms 的三步结构
该文件每行格式固定：[address] [tT] [symbol_name]，例如 ffffffff81000000 T _text。C++ 解析不能只靠 std::getline + std::stringstream 硬切，因为符号名里可能含空格（如 __crc___kmpc_begin 不会，但某些模块符号会）。
推荐用 sscanf 做字段锚定：
立即学习“C++免费学习笔记（深入）”；
char line[512];
while (fgets(line, sizeof(line), fp)) {
unsigned long addr;
char ttype, name[256];
// 严格按“16进制+空格+单字符+空格+剩余字符串”解析
if (sscanf(line, "%lx %c %255s", &addr, &ttype, name) == 3) {
// 成功提取：addr 是地址，ttype 是符号类型（T/t 表示全局/局部函数），name 是符号名
}
}
- 不用
std::stoi或std::stoul直接转字符串，因为前缀0x不统一（有的带，有的不带） -
ttype区分大小写：T（全局文本）、t（局部文本）、R（只读数据）、r（局部只读）等，调试时重点关注T和R - 符号名长度限制必须显式指定（如
%255s），否则缓冲区溢出风险极高
读取失败的三个典型错误现象及对应检查点
即使 kptr_restrict=0，C++ 程序仍可能读不到有效符号，常见于以下场景：
- 程序以普通用户运行，且
/proc/kallsyms权限为-r--------（只允许 root）→ 检查ls -l /proc/kallsyms，确认进程 uid 为 0 或已加cap_syslog能力 - 内核启用了
CONFIG_KALLSYMS_ALL但未开启CONFIG_KALLSYMS→ 此时/proc/kallsyms根本不存在，需重新编译内核或换发行版（主流 distro 默认都开） - 使用
std::ifstream但未检查is_open()，或忽略failbit导致后续getline返回空 → 必须在open后立刻验证状态
性能与兼容性注意事项
/proc/kallsyms 是虚拟文件，每次读取都会触发内核遍历符号表，文件大小常超 10MB（>50 万行）。C++ 程序若频繁打开-关闭-重读，会显著拖慢启动速度。
- 不要在热路径（如每帧调用）中重复读取；建议启动时一次性加载进
std::unordered_map<:string uint64_t></:string> - 符号地址是内核态虚拟地址，不能直接用于用户态指针运算；若需做 kprobe 或 eBPF 开发，必须配合
/boot/System.map-$(uname -r)或vmlinux文件做符号重定位 - 不同内核版本符号命名可能变化（如
__do_fault在 5.10+ 改为__handle_mm_fault），硬编码符号名极易失效
真正难的不是读文件，而是确认你要找的符号是否被导出、是否在当前内核配置下存在、以及地址拿到后怎么安全使用——这些都得结合 nm vmlinux 和 grep 手动交叉验证。
