必须加-g编译，否则cachegrind无法映射行号；因缺失dwarf调试符号，报告仅显示地址而非源码位置，且strip或lto等操作会进一步破坏符号可读性。
必须加 -g 编译，否则 cachegrind 无法映射行号——这不是可选优化，是硬性前提。
为什么 cachegrind 报告里全是地址、没有文件和行号
根本原因是可执行文件缺失调试符号。cachegrind 依赖 DWARF 信息把内存地址反查到源码位置，而 -g 是生成该信息的唯一可靠方式。即使你用了 -O2 或 -O3，只要保留 -g（比如 g++ -O2 -g main.cpp），行号就能正常显示；但若编译时漏掉 -g，或用了 strip 处理二进制，cachegrind 就只能输出类似 0x401234 的地址，cg_annotate 也无从关联源码。
常见误操作包括：
- 用
make release或cmake -DCMAKE_BUILD_TYPE=Release构建，默认关掉-g - CI 流水线中打包前执行了
strip ./myapp - 交叉编译时 CFLAGS 里写了
-g，但链接阶段没传给ld（需确认-g出现在最终g++ ... -o myapp命令中）
cachegrind 输出里出现 ???:??? 或空函数名
这说明符号存在但不完整：可能是内联函数被折叠、模板实例化未导出，或编译器用了 -flto（Link Time Optimization）。LTO 会延迟符号生成到链接期，导致 cachegrind 在运行时看不到函数定义位置。
解决办法很直接：
- 临时禁用 LTO：移除编译和链接参数里的
-flto和-fuse-linker-plugin - 保留内联可见性：加
-fno-semantic-interposition（可选，减少符号隐藏） - 验证是否生效：运行
readelf -w ./myapp | head -5，应看到Abbrev Offset:和非空的调试节；若输出为空或报错No DWARF info，说明-g没生效
交叉编译环境（如 aarch64-musl）下调试信息丢失
交叉工具链常默认关闭调试支持，或生成的 DWARF 版本不被 Valgrind 兼容。你贴出的构建命令里虽然有 -g 和 -ggdb3，但问题可能出在：
- 工具链本身不带 DWARF 支持（检查
aarch64-openwrt-linux-musl-gcc -v输出中是否含dwarf） -
-g被后续参数覆盖（例如-Os后又写-g，但某些旧版 GCC 会忽略） - 目标系统 glibc/musl 版本太老，Valgrind 解析 DWARF 失败（此时
cachegrind日志里会出现Warning: DWARF xxx not supported）
实操建议：
- 强制指定 DWARF2：
-gdwarf-2（兼容性最强） - 避免混合调试格式：
-g和-ggdb3不要同时用，选一个即可 - 在目标机上运行
file ./myapp，确认输出含with debug_info字样
已经生成的无调试信息二进制，还能补救吗
不能。DWARF 符号在编译时嵌入，运行时无法注入。你只能重新编译。但可以快速验证当前二进制状态：
-
objdump -h ./myapp | grep debug—— 应列出多个.debug_*节 -
nm -C ./myapp | grep main—— 若输出含T main（大写 T 表示已定义），说明符号未被 strip；若只有地址无符号名，则已损坏
最易被忽略的一点：cachegrind 不报错也不警告“没符号”，它只是静默降级为地址模式。所以看到报告里没有行号，第一反应不应该是调参或换工具，而是立刻检查 file 和 objdump 输出——这是唯一能确认问题根源的动作。
