gdb – 远程事后coredump分析,没有共享系统库的确切调试符号

概述你怎么经常解决这个问题？想象一下,线程在Computer1上的libc代码(这是一个系统共享库)内崩溃,然后生成一个coredump.但是,将分析此coredump的Computer2可能具有不同版本的libc. 所以： >在远程计算机上拥有相同的共享库有多重要？ gdb会在Conputer2上没有完全相同版本的libc的情况下正确重建stacktrace吗？ >为libc提供正确的调试符号有多重 你怎么经常解决这个问题？想象一下,线程在Computer1上的libc代码(这是一个系统共享库)内崩溃,然后生成一个coredump.但是,将分析此coredump的Computer2可能具有不同版本的libc.

所以：

>在远程计算机上拥有相同的共享库有多重要？ gdb会在Conputer2上没有完全相同版本的libc的情况下正确重建stacktrace吗？
>为libc提供正确的调试符号有多重要？ gdb会在Computer2上没有完全相同的调试符号的情况下正确地重建堆栈跟踪吗？
>对于共享系统库,避免此调试符号不匹配问题的“正确”方法是什么？对我来说似乎没有单一的解决方案以优雅的方式解决这个问题？也许有人可以分享他的经历？

解决方法 >这取决于.在某些处理器(例如x86_64)上,GDB需要正确的 unwind descriptors才能正确展开堆栈.在这样的机器上,用不匹配的libc分析coredump可能会产生完全垃圾.
> libc不需要调试符号来获取堆栈跟踪.如果没有调试符号,您将无法获得文件和行号,但是您应该获得正确的函数名称(除非在进行内联时).
>你的问题的前提是错误的 – 调试符号与此无关.在C1上生成coredump时,分析C2上coredump的“正确”方法是获得C1库的副本(例如/ tmp / C1 / lib / …)并指示GDB使用该副本而不是C2安装了libc

(gdb)设置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也将转储只读映射,因此您可以在任何计算机上分析核心.

总结

以上是内存溢出为你收集整理的gdb – 远程事后coredump分析,没有共享系统库的确切调试符号全部内容，希望文章能够帮你解决gdb – 远程事后coredump分析,没有共享系统库的确切调试符号所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。