必须加-g编译，否则Cachegrind无法映射到源码行；-g提供调试信息以显示文件名和行号，缺之则输出全是???:?或汇编地址，且需避免-strip、-pg等干扰选项。
编译时必须加 -g，否则 Cachegrind 无法映射到源码行
Cachegrind 本身不参与编译，但它严重依赖调试信息来报告函数、行号、指令归属。没 -g 编译出来的二进制，Cachegrind 只能显示汇编地址或问号，基本没法分析。
常见错误现象：cachegrind_annotate --auto=yes cachegrind.out.xxx 输出全是 ???:? 或 0x...: 地址，没有文件名和行号。
- 务必在
gcc/clang编译命令中加入-g - 如果用了
-O2或更高优化级，建议同时加-g3（保留宏和内联信息），但注意-O2会重排/内联代码，部分行号可能失准 - 避免加
-s（strip）或-fomit-frame-pointer，前者直接删调试段，后者让调用栈解析失败
不需要 -pg 或链接额外库
-pg 是 gprof 的专用标记，Cachegrind 完全不依赖它。加了不仅没用，还可能因插入 profiler hook 导致行为异常或报错。
也不需要链接任何 Valgrind 相关的库（比如 -lvalgrind），Cachegrind 是运行时插桩工具，对目标程序是零侵入的——你编译出来的就是普通可执行文件，只是得带调试信息。
- 确认编译命令不含
-pg、-finstrument-functions等 profiling 专用选项 - 静态链接或动态链接都 OK，只要最终二进制含
.debug_*段（可用readelf -S your_binary | grep debug验证） - 如果项目用 CMake，确保
CMAKE_BUILD_TYPE不是Release（默认无-g），推荐用Debug或自定义RelWithDebInfo
交叉编译或 stripped 产物怎么补救
如果只能拿到一个 stripped 的发布版二进制，又没源码或构建环境，Cachegrind 基本无法有效工作——它不能凭空恢复符号和行号。
唯一可行的补救路径是：找对应版本的未 strip 的 binary 或 .debug 分离文件，并通过 VALGRIND_DEBUG_FILE_PATH 环境变量指定路径，或用 objcopy --add-section .debug=/path/to/debugfile binary 合并回去（需匹配 build-id）。
- 开发阶段就该保留带
-g的构建产物，别等上线后才想分析 cache 行为 - CI 中可加检查：
file your_binary | grep "with debug info"，避免漏掉-g - 对于 Rust/C++ 模板-heavy 项目，
-g生成的调试信息体积可能很大，但这是必须付出的代价；可用dwz压缩.debug_*段（不影响 Cachegrind 使用）
Cachegrind 对编译的要求其实非常朴素：只认 -g，其他都是干扰项。最容易被忽略的是，在 Makefile 或 CI 脚本里把 -g 写在某个子目录的 CFLAGS 里，却忘了主程序或关键 shared library 的编译命令里也得有。
