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

Question

I am working on a project, where the request "we want more information in release build stack traces" came up.

With "stack trace" I mean basically the output of taa bt in gdb , which I suppose to be equivalent to the output of gstack for a running process. If this is true would be one of my questions.

My main problem is that availability of stack traces is rather erratic (sometimes you have them, sometimes you don't) and documentation could be more detailed (eg gdb documentation states that " -fomit-frame-pointer makes debugging impossible on some machines.", without any clear information about x86_64)

Also, when examining a running program with gstack , I get a quite perfect stack traces. I am unsure, though, if this is exactly what I would get from a core dump with gdb (which would mean that all cases where I get less information, the stack has been really corrupted).

Currently, the code is compiled with -O2 . I have seen one stack trace lately, where our own program code's stack frames did not have any function parameter values, but the first (inner) frames, where our code already called a third party library, provided these values. Here, I am not sure if this is a sign that the first party library had better gcc debugging options set, or if these information is just lost at some point iterating down the stack trace.

I guess my questions are:

• Which compiler options influence the stack trace quality on x86_64
• are stack traces from these origins identical:
  • output of gstack of a running program
  • attached gdb to a running program, executed taa bt
  • called gcore on a running program, opening core with gdb , then taa bt
  • program aborted and core file written by system, opened with gdb
• Is there some in-depth documentation which parameters affect stack trace quality on x86_64?

All considerations made under the assumption that the program binary exists for the core dump, and source code is not available.

With "quality of a stack trace" i mean 3 criteria:

• called function names are available, not just "??"
• The source codes file name and line number is available
• function call parameters are available.

Answer 1

Which compiler options influence the stack trace quality on x86_64

The -fomit-frame-pointer is the default on x86_64 , and does not cause stack traces to be unusable.

GDB relies on unwind descriptors, and you could strip these with either strip or -fno-unwind-tables (this is ill -advised).

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

Last I looked, gstack was a trivial shell script that invoked gdb , so yes.

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

Yes.

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

Yes, provided the core is opened with GDB on the same system where gcore was run.

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

Same as above.

If you are trying to open core on a different system from the one where it was produced, and the binary uses dynamic libraries, you need to set sysroot appropriately. See this question and answer.

Note that there are a few reasons stack may look corrupt or unavailable in GDB:

• -fno-unwind-tables or strip ing mentioned above
• code compiled from assembly, and lacking proper .cfi directives
• third party libraries that were built with very old compiler, and have incorrect unwind descriptors (anything before gcc-4.4 was pretty bad).
• and finally, stack corruption.