GDB调用栈显示地址而非函数名，主因是二进制缺失DWARF调试信息：编译未加-g、被strip删除、Rust名称修饰未解码、或栈被破坏导致回溯失效。
GDB调用栈里全是地址（比如 0x401123），没有函数名和文件行号，说明调试符号没被正确加载或已损坏。这不是GDB坏了，而是二进制里根本没存这些信息——必须回编译阶段补救。
为什么 backtrace 显示问号或地址而不是函数名
最常见原因是可执行文件缺失 DWARF 调试信息。GDB 依赖这些元数据把机器指令映射回源码，一旦缺失，backtrace 就只能打印裸地址。典型现象包括：
#0 0x00005555555551a2 in ?? ()#1 0x00005555555552b8 in ?? ()- 用
info functions查不到任何函数名
这通常不是运行时问题，而是编译时就埋下的坑。别急着重装 GDB，先检查二进制本身是否带符号：
file ./myapp readelf -S ./myapp | grep debug
如果输出里没有 .debug_* 段，那基本可以确定：没加 -g，或者后续被 strip 过了。
gcc/g++ 编译必须带 -g，且不能被 strip 掉
只加 -g 不够，还得防“二次破坏”。常见翻车点：
- 编译命令漏了
-g：正确写法是gcc -g -O0 -o myapp main.c（-O0避免优化干扰符号位置） - 链接后手动执行
strip ./myapp：这会直接删掉所有.debug_*段，不可逆 - 使用
make install时触发了隐式 strip：检查 Makefile 或 CMakeLists.txt 是否含INSTALL_TARGETS+STRIP相关逻辑 - 容器或 CI 构建中用了 alpine 等精简镜像：默认工具链可能不带调试信息支持，需显式安装
glibc-dbg或对应 debuginfo 包
Rust 程序的符号问题更隐蔽：名称修饰 + 优化干扰
Rust 默认启用名称修饰（mangling），且 --release 模式下默认开启 LTO 和内联，导致 GDB 看不到原始函数名或变量值。关键动作：
- 确保
Cargo.toml中 dev profile 启用完整调试信息：debug = true（等价于debuginfo = 2） - 在 GDB 中启用自动解码：
set print demangle on和set demangle-style rust - 避免在
backtrace中看到_RNvCs...类似乱码 - 若变量显示
<optimized out>，不是符号缺失，而是优化抹掉了变量存储——必须用opt-level = 0重建
顺手验证：运行 nm -C ./target/debug/myapp | grep calculate_sum，应能直接看到可读函数名；若仍是修饰后的符号，说明 debuginfo 没生效。
core 文件里调用栈全乱？大概率是栈内存被破坏
即使二进制带完整符号，gdb ./myapp core 后 backtrace 仍显示 ??，尤其是某个线程的栈帧断层、地址跳跃、甚至全是问号——这不是符号问题，是程序崩溃前已经把栈搞坏了（比如缓冲区溢出覆盖了返回地址、栈指针被篡改）。
此时不能只盯 backtrace，要转向底层证据：
- 用
info registers看rsp/rbp是否明显异常（如指向非法地址、远超正常栈范围） - 用
x/20xg $rsp手动 dump 栈顶内存，观察是否有连续的疑似返回地址（规律性 0x40xxxxxx 或 0x55xxxxxx） - 用
thread apply all bt full对比所有线程，若仅一个线程崩得离谱，基本可锁定为该线程的内存越界或 use-after-free
这种情况下，符号表本身是完好的，只是崩溃现场已无法还原调用路径——得靠 ASan/UBSan 提前拦截，而不是指望 GDB 回溯。
真正难处理的不是“看不到函数名”，而是你以为符号有了，结果发现是栈被踩坏、是 Rust 名称修饰没解码、是 release 构建里变量被优化掉。每个场景的修复入口完全不同，得先分清：是编译没给，还是给了但被破坏，还是给了但 GDB 没认出来。
