在 i386 上实现回溯答案

【问题标题】：Implementing traceback on i386在 i386 上实现回溯
【发布时间】：2010-03-08 09:52:06
【问题描述】：

我目前正在将我们的代码从 alpha (Tru64) 移植到 C 中的 i386 处理器 (Linux)。一切都很顺利，直到我考虑移植我们的异常处理例程。目前我们有一个父进程产生许多子进程，当这些子进程之一致命的（未执行的）我有例程来捕捉这个过程。

我目前正在努力寻找实现追溯例程的最佳方法，该例程可以列出错误日志中的函数地址，目前我的例程只打印导致异常的信号和异常限定符代码。

任何帮助都会得到极大的帮助，理想情况下我会为所有处理器编写错误处理，但是在这个阶段我只关心 i386 和 x86_64。

谢谢

标记

【问题讨论】：

【解决方案1】：

来自execinfo.h 的glibc 函数backtrace() 和backtrace_symbols() 可能有用。

【讨论】：

【解决方案2】：

您可以查看http://tlug.up.ac.za/wiki/index.php/Obtaining_a_stack_trace_in_C_upon_SIGSEGV。它涵盖了您需要的功能。但是，您必须链接 libgdb 和 libdl，使用 -rdynamic 编译（在可执行文件中包含更多符号），并放弃使用一些优化。

【讨论】：

【解决方案3】：

有两个 GNU（非 POSIX）函数可以帮助您 - backtrace() 和 backtrace_symbols() - 首先返回函数地址数组，然后将地址解析为名称。不幸的是，静态函数的名称无法解析。

要使其正常工作，您需要使用 -rdynamic 标志编译二进制文件。

【讨论】：

【解决方案4】：

不幸的是，没有“最佳”方法，因为堆栈的布局可能因 CPU、操作系统和用于编译代码的编译器而异。但是this article may help。

注意，你必须在子进程中实现这个；父进程只是得到一个错误的信号；您没有获得子堆栈的副本。

【讨论】：

很抱歉造成混乱，但错误处理被误解了，它确实被子进程捕获了。另请注意，我使用的是 GNU 编译器 (gcc)。
在这种情况下，这篇文章应该回答你所有的问题。请注意，您必须使用-fno-omit-frame-pointer 进行编译（否则%ESP 将不包含有效数据）。

【解决方案5】：

【讨论】：

【解决方案6】：

如果您在运行 valgrind 时只获得适当的回溯没问题，那么这可能是您的一个选择：

VALGRIND_PRINTF_BACKTRACE（格式，...）：

它将为您提供所有函数的回溯，包括静态函数。

【讨论】：