Han*_*olo 7 gdb remote-debugging shared-libraries postmortem-debugging
你怎么经常解决这个问题？想象一下,线程在Computer1上的libc代码(这是一个系统共享库)内崩溃,然后生成一个coredump.但是,将分析此coredump的Computer2可能具有不同版本的libc.
所以:
在远程计算机上拥有相同的共享库有多重要？gdb会在Conputer2上没有完全相同版本的libc的情况下正确重建stacktrace吗？
为libc提供正确的调试符号有多重要？gdb会在Computer2上没有完全相同的调试符号的情况下正确地重建堆栈跟踪吗？
什么是避免共享系统库的调试符号不匹配问题的"正确"方法？对我来说,似乎没有单一的解决方案以优雅的方式解决这个问题？也许有人可以分享他的经历？
Emp*_*ian 13
这取决于.在某些处理器上,例如x86_64,GDB需要正确的展开描述符才能正确展开堆栈.在这样的机器上,用不匹配的libc分析coredump可能会产生完全垃圾.
libc不需要调试符号来获取堆栈跟踪.如果没有调试符号,您将无法获得文件和行号,但是您应该获得正确的函数名称(除非在进行内联时).
你的问题的前提是错误的 - 调试符号与此无关.在C1上生成coredump时,分析C2上coredump的"正确"方法是获得C1库的副本(例如/tmp/C1/lib/...)和直接GDB使用该副本而不是C2安装libc的
(gdb) set solib-absolute-prefix /tmp/C1
命令.
注意:在将核心加载到GDB之前,上述设置必须生效.这个:
gdb exe core
(gdb) set solib-absolute-prefix /tmp/C1
不起作用(在设置生效之前读取核心).
这是正确的方法:
gdb exe
(gdb) set solib-absolute-prefix /tmp/C1
(gdb) core core
(我试图在网上找到对此的引用,但没有).
什么是展开描述符？
在没有帧指针的情况下编译代码时需要展开描述符(在优化模式下默认为x86_64).这样的代码并没有保存%RBP寄存器,所以GDB需要被告知如何从当前帧"退一步"给调用者框架(这个过程也被称为堆栈展开).
为什么C1的libc.so不包含在核心中？
核心文件通常仅包含程序地址空间的可写段的内容.通常不需要只读段(可执行代码和展开描述符所在的段) - 您可以直接从磁盘上的libc.so读取它们.
当你在C2上分析C1的核心时,这不起作用!
一些(但不是全部)操作系统允许人们配置"完整的coredumps",其中OS也将转储只读映射,因此您可以在任何计算机上分析核心.