c++ - 发布代码的 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

Which compiler options influence the stack trace quality on x86_64

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

GDB 依赖于展开描述符，您可以使用 strip 或 -fno-unwind-tables 剥离它们(这是 生病-建议)。

are stack traces from these origins identical:
- output of gstack of a running program

我最后看了看，gstack 是一个调用 gdb 的普通 shell 脚本，所以是的。

• attached gdb to a running program, executed "t a a bt"

是的。

• called gcore on a running program, opening core with gdb, then "t a a bt"

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

• program aborted and core file written by system, opened with gdb

同上。

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

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

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