在尝试分析 GDB 中的核心转储（由断言中的 SIGABRT 转储的进程）的回溯时，我得到以下输出：
(gdb) bt
#0 0x76d6bc54 in raise () from ./lib/libc.so.1
#1 0x76d63bb8 in abort () from ./lib/libc.so.1
Backtrace stopped: frame did not save the PC
(gdb) thread apply all bt
二进制文件是用“-g”编译的，所以除了工具链中的链接库（例如，甚至没有符号的 libc）之外，所有链接库也是如此，我无法确定它是如何构建的。
这是堆栈损坏还是 libc 使用“fomit-frame-pointer”之类的东西编译的结果。
作为一般问题，如果运行时链接库发生未捕获的异常并且该库不是为调试而构建的，会发生什么，即核心转储是否仍包含有用的信息？
谢谢
【问题讨论】：
标签： c gdb coredump toolchain backtrace
我认为罪魁祸首是应用程序正在加载的 libc。它可能是用一些使 coredump 无用的选项编译的。我所做的是创建一个自定义工具链（使用从 buildroot 编译的工具链）并使用该工具链编译和运行应用程序。然后我能够成功读取核心转储。
【讨论】：
改进包含来自共享对象的函数但没有调试符号的回溯的一种方法是在 gdb 可以看到它们的位置安装调试符号。如何执行此操作的详细信息取决于您的环境。一个例子是，如果 libc.so.6 由 Debian 系统上的 libc6 软件包提供，安装 libc6-dbg 软件包会在 /usr/lib/debug/.build-id 下放置许多符号表（libc6 软件包，除了 libc.so.6 , 提供了许多其他剥离的共享对象）。如果您正在为非本机内核使用调试器环境（正如 ./lib/libc.so.1 中领先的 . 所建议的那样），您可能会提取这样的软件包而不是安装它（在 Debian 系统上 dpkg -x 是一种方法这样做）。
除了调试符号的问题，在某些情况下，您可以通过确保 gdb 看到的共享对象（已剥离或以其他方式）正确对应于转储核心的进程正在使用的共享对象来改进回溯.一种检查方法是比较构建 ID，它们（在典型的 Linux 系统上）由 file 命令报告。仅当您能够可靠地确定在核心转储时正在使用哪些共享对象，并且假定您的共享对象是以包含构建 ID 的方式构建时，这才有帮助。
在某些情况下，可执行文件和所有相关共享对象的构建 ID 可以可靠地从核心文件本身中提取。在 Linux 系统上，这需要在核心中存在文件注释，并且存在可执行文件和每个共享对象的第一页。最近配置了典型默认值的 Linux 内核包括所有这些。
https://github.com/wackrat/structer 提供了从满足其假设的核心文件中提取构建 ID 的 python 代码。根据核心文件的大小，使用 64 位系统可能更可取，即使核心本身来自 32 位系统。
如果事实证明 gdb 正在为此核心使用正确的共享对象（或者如果没有可行的方法来确认或反驳），另一种可能性是反汇编 gdb 报告的两个堆栈帧中的代码。如果 gdb 看到的共享对象不是该核心的正确对象，那么该反汇编可能是神秘的，因为 gdb 依赖于它使用的共享对象的内容来与核心文件时该位置的内容对齐已转储（只读段通常从核心文件中排除，但提供每个构建 ID 的第一页除外）。根据我的经验，即使没有帧指针，gdb 通常也可以在没有调试符号的情况下提供连贯的回溯，但如果使用了错误的共享对象，gdb 可能会基于与该位置的正确内容不对应的指令进行回溯。
【讨论】：