发布代码的 gdb 堆栈跟踪可读性如何影响 x64？

Question

我正在处理一个项目，其中出现了“我们希望在发布构建堆栈跟踪中获得更多信息”的请求。

对于“堆栈跟踪”，我的意思基本上是gdb 中的输出of t a a bt，我认为它相当于正在运行的进程的gstack 输出。如果这是真的，那将是我的问题之一。

我的主要问题是堆栈跟踪的可用性相当不稳定（有时你有它们，有时你没有）并且文档可能更详细（例如gdb 文档指出“-fomit-frame-pointer 使得在某些情况下无法调试机器。”，没有关于 x86_64 的任何明确信息）

另外，当使用gstack 检查一个正在运行的程序时，我得到了一个非常完美的堆栈跟踪。不过，我不确定这是否正是我从带有gdb 的核心转储中得到的结果（这意味着在我获得较少信息的所有情况下，堆栈都已真正损坏）。

目前，代码使用-O2 编译。我最近看到了一个堆栈跟踪，我们自己的程序代码的堆栈帧没有任何函数参数值，但是我们的代码已经调用第三方库的第一个（内部）帧提供了这些值。在这里，我不确定这是否表明第一方库设置了更好的 gcc 调试选项，或者这些信息是否只是在迭代堆栈跟踪时丢失了。

我想我的问题是：

• 哪些编译器选项会影响 x86_64 上的堆栈跟踪质量
• 来自这些来源的堆栈跟踪是否相同：
  • 正在运行的程序的gstack 的输出
  • 将gdb附加到正在运行的程序，执行t a a bt
  • 在一个正在运行的程序上调用gcore，用gdb打开核心，然后t a a bt
  • 程序中止，系统写入核心文件，以gdb打开
• 是否有一些深入的文档，哪些参数会影响 x86_64 上的堆栈跟踪质量？

所有考虑因素都假设存在核心转储的程序二进制文件，并且源代码不可用。

“堆栈跟踪的质量”是指 3 个标准：

• 调用的函数名可用，而不仅仅是“??”
• 源代码文件名和行号可用
• 函数调用参数可用。

Answer 1

哪些编译器选项会影响 x86_64 上的堆栈跟踪质量

-fomit-frame-pointer 是 x86_64 的默认值，不会导致堆栈跟踪不可用。

GDB 依赖于展开描述符，您可以使用strip 或-fno-unwind-tables 剥离这些描述符（这是不建议建议的）。

来自这些来源的堆栈跟踪是否相同：
- 正在运行的程序的 gstack 输出

我最后看了一下，gstack 是一个简单的 shell 脚本，它调用了 gdb，所以是的。

• 将 gdb 附加到正在运行的程序，执行“t a a bt”

是的。

• 在正在运行的程序上调用 gcore，用 gdb 打开核心，然后“t a a bt”

是的，提供core在运行gcore的相同系统上使用GDB打开。

• 程序中止，系统写入核心文件，用gdb打开

同上。

如果您尝试在与生成它的系统不同的系统上打开core，并且二进制文件使用动态库，您需要适当地set sysroot。见this问答。

请注意，堆栈在 GDB 中可能看起来已损坏或不可用有几个原因：

• 上面提到的-fno-unwind-tables或striping
• 从汇编编译的代码，缺少正确的.cfi 指令
• 使用非常旧的编译器构建的第三方库，并且具有不正确的展开描述符（gcc-4.4 之前的任何东西都非常糟糕）。
• 最后，堆栈损坏。