GDB 在核心文件上使用“符号文件”命令读取符号答案

【问题标题】：GDB reading symbols with "symbol-file" command on a core fileGDB 在核心文件上使用“符号文件”命令读取符号
【发布时间】：2019-07-28 09:45:01
【问题描述】：

我正在尝试分析 linux 上核心文件的段错误。我不确定以下行为是否正确，因此我故意使用

造成了段错误

#include <signal.h>
int main() {
raise(SIGSEGV); 
}

二进制文件是使用调试信息构建的，即

file mainTestFile 
mainTestFile: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, with debug_info, not stripped

注意它最后是如何说“带有 debug_info，未剥离”

当我执行二进制文件时，我会生成一个名为 core-mainTestFile.20474 的核心文件（为了生成核心文件，我将我的 ulimit 设置为无限制，即 ulimit -c 无限制 )

如果我只在 GDB 下运行二进制文件并执行回溯“bt”，那么我会得到 segfault，并且我会得到所涉及函数的所有名称打印得很好，即注意 gdb 在开始“从 ./mainTestFile...done 读取符号”时的说法。

gdb ./mainTestFile
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git

....

reading symbols from ./mainTestFile...done.
(gdb) run
Starting program: /src/exe/mainTestFile 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".


Program received signal SIGSEGV, Segmentation fault.
__GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x0000000000402dad in main (argc=1, argv=0x7fffffffda38) at /src/exe/main.cpp:53
(gdb)

但是，如果我尝试像这样使用 gdb 仅分析核心文件

gdb -c core-mainTestFile.20474

那我只得到问号

当我执行“bt”时，我看不到方法的名称，而是得到问号

(gdb) bt
#0  0x00007f34d8842e97 in ?? ()
#1  0x0000000000000000 in ?? ()

我发现他们唯一的解决方法是直接在命令行中提供二进制文件，然后一切都会很好地打印出来。即使我试图告诉 GDB 使用符号文件并将其指向具有符号的二进制文件即

symbol-file /src/exe/mainTestFile

然后 GDB 说

Reading symbols from /src/exe/mainTestFile...done

当我执行 bt 时，我再次看到问号？这是为什么。 GDB 无法从二进制文件中获取符号吗？

它只有在直接在命令上提供二进制文件时才有效，例如：

gdb /src/exe/mainTestFile -c core-mainTestFile.20474

我的问题是 GDB 在通过“符号文件”命令直接向他提供二进制文件时是否能够读取二进制文件的符号。为什么在命令行上直接向他提供二进制文件时这会起作用，有什么区别？

【问题讨论】：

标签： c++ gdb core-file

【解决方案1】：

当通过“symbol-file”命令直接向他提供二进制文件时，GDB 是否应该能够读取二进制文件的符号。

理论上，在 GDB 中以 either 顺序使用 symbol-file 和 core-file 命令应该是等效的。

但有一个错误：symbol-file 后跟 core-file 有效，而相反的顺序无效。

由于通常最终用户总是可以将他的命令重新排列为有效的顺序，因此这从未传播到任何 GDB 开发人员要修复的事情队列的顶部。