必须加-g，否则Massif无法显示函数名、行号等关键内存分配上下文，因其依赖DWARF调试信息将内存地址映射回源码位置；无-g时堆栈仅显示(below main)或十六进制地址，完全无法定位问题代码。
必须加 -g，否则 Massif 无法显示函数名、行号等关键内存分配上下文。
为什么 -g 对 Massif 不是可选而是必需
Massif 本身不分析源码，但它依赖调试信息（DWARF）把内存分配地址映射回函数名、文件名和行号。没有 -g 编译，massif.out.* 中的 allocs 和 heap_tree 节点只会显示 (below main) 或十六进制地址，完全无法定位哪段代码在分配内存。
- 即使只关心总堆大小趋势，也建议加
-g——后续若需排查某次 spike，没符号信息就只能靠猜 -
-g不影响 Massif 的采样逻辑或性能开销，只增加二进制体积（通常几 MB 内） - 用
strip去掉符号后运行 Massif，结果等同于未加-g编译
-g 和 -O2 能否共存
可以，且推荐组合使用：gcc -g -O2 -o prog prog.c。
- Massif 的堆快照机制基于运行时拦截
malloc/new等调用，与优化级别无关 -
-O2可能导致某些局部变量被优化进寄存器或内联，使部分小分配“消失”在调用栈中，但这属于真实行为，不是 Massif 的缺陷 - 若为彻底还原源码结构而牺牲性能，可用
-g -O0；但生产级排查更应保留-O2，否则内存模式可能失真
常见错误：加了 -g 却仍看不到函数名
这通常不是编译问题，而是 Massif 运行或解析环节出错：
- 忘记用
--time-unit=B或--detailed-freq=1等参数开启详细模式，导致输出被压缩 - 用
valgrind --tool=massif ./prog但程序很快退出，生成的massif.out.*文件太小，没捕获到有效分配栈 - 用
ms_print massif.out.*查看时，终端宽度不足导致长函数名被截断——加--width=200可缓解 - 链接了静态库（如
libxyz.a），但该库未用-g编译，对应分配点仍显示为???
真正麻烦的是混合编译场景：主程序加了 -g，但依赖的第三方静态库没带调试信息。这时 Massif 报告里会出现“断层”——顶层函数可见，下一层就变成地址。这种情况只能联系库提供方索要带 -g 的版本，或改用共享库（.so）并确保其调试包已安装。
