GDB不识别C++对象语义，仅通过内存地址、符号表和DWARF信息还原对象状态；需-g编译保留调试信息，再结合bt full、info locals、print *obj和ptype等命令定位并验证对象内存布局与字段值。
core里没有“对象”概念，只有内存和符号
GDB 本身不识别 C++ 的 class、this 指针或虚函数表这些语义层的东西。它看到的只是内存地址、寄存器值、符号表（如果有 -g 编译）和 DWARF 调试信息。所谓“看对象状态”，本质是：定位到该对象所在的内存地址 → 解析其内存布局 → 结合类型信息还原字段值。
前提是程序必须用 -g 编译，且未 strip 掉调试信息；否则 print 出来的可能只是 {...} 或报 No symbol "xxx" 错误。
怎么定位对象的内存地址
崩溃时对象通常在栈上（局部对象）、堆上（new 出来）、或全局/静态区。GDB 不会自动告诉你“这个对象叫什么”，得靠调用栈和变量名反推：
- 先用
bt full查看崩溃帧，注意当前栈帧里的参数和局部变量名，比如std::string s、MyClass* obj - 用
info locals或info args列出当前作用域变量及其地址，例如：s = {static npos = 18446744073709551615, _M_dataplus = {...}}，其中_M_dataplus的地址就是底层数据起始点 - 如果对象是通过指针访问的（如
obj->method()崩溃），print obj能直接看到指针值，再用print *obj尝试解引用——但要注意指针是否为空或已释放
用 print 和 ptype 还原字段值
print 是核心操作，但它依赖调试信息是否完整。常见情况：
-
print *obj：尝试按对象类型打印整个结构体内容（需符号可用） -
print obj->field_name：直接访问字段，比手动计算偏移更可靠 -
ptype MyClass：查看类定义，确认字段顺序、大小、是否有虚表指针（vptr通常在对象开头） -
x/4xg obj：若符号丢失，可手工查看对象起始地址的 4 个 8 字节（x86_64），对照ptype输出的内存布局推测字段位置
注意：虚继承、多重继承会让内存布局复杂化，ptype 输出的字段偏移可能不连续；此时 print *obj 仍能工作，但手工 x 查看容易错位。
容易被忽略的坑：对象生命周期和内存有效性
core 文件是快照，但快照里的地址未必指向有效对象：
- 堆对象如果已被
delete，其内存可能被复用或清零，print *ptr可能显示乱值甚至触发 GDB 报错Cannot access memory at address... - 栈对象在函数返回后就失效，但 core 里仍保留栈帧内存——只要没被后续调用覆盖，
bt full中的info locals通常还能读出来 - STL 容器（如
std::vector）内部指针可能指向已释放内存，print vec显示 size 正常但 data 段不可读，这时要结合info proc mappings看该地址是否还在进程映射范围内
真正难的不是“怎么 print”，而是判断 print 出来的值是否可信——这需要交叉验证调用栈、信号类型（比如 SIGSEGV 崩溃点附近的指针大概率非法）、以及代码逻辑中对象本该处于什么状态。
