核心转储本身是否可执行？答案

【问题标题】：Is a core dump executable by itself?核心转储本身是否可执行？
【发布时间】：2013-08-05 18:35:26
【问题描述】：

Core dump 上的维基百科页面说

在类 Unix 系统中，核心转储通常使用标准可执行文件图像格式：
a.out in older versions of Unix,
ELF in modern Linux, System V, Solaris, and BSD systems,
Mach-O in OS X, etc.

这是否意味着核心转储本身可以执行？如果不是，为什么不呢？

编辑：由于@WumpusQ.Wumbley 在评论中提到了coredump_filter，也许上面的问题应该是：可以生成核心转储以使其自身可执行吗？

【问题讨论】：

如果执行核心转储，您会期待什么结果？
我相信（但不确定）核心转储也包含来自原始可执行文件的机器指令，因为它们是进程内存映像的一部分。如果是这样，我希望它能够运行这些指令。我完全不清楚这是否会发生，如果会发生，它是否会重新开始，或者会尝试从存储的状态继续执行（并且可能再次崩溃），因此是个问题。
取消转储：code.google.com/p/undump
@WumpusQ.Wumbley 谢谢，这正是我希望从中学到的有趣的东西。 undump 似乎需要原始可执行文件和核心转储，所以看起来核心转储只有数据，没有可执行代码？
核心转储是否包含文本段取决于一些配置选项。例如，请参阅 man7.org/linux/man-pages/man5/core.5.html 中的 coredump_filter 部分。我认为传统的 unix 行为是包含它，因此核心转储将拥有一切。假设用户能够找到可执行文件并将其与核心文件配对，则省略它以使核心转储更便宜，这是最近的发展。但是找不到任何证据来支持我的回忆。

标签： linux unix executable coredump executable-format

【解决方案1】：

正如其他人所说，我认为没有原始二进制文件就无法执行核心转储文件。

如果您有兴趣调试二进制文件（并且它包含调试符号，也就是说它没有被剥离），那么您可以运行gdb binary core。

在 gdb 中，您可以使用bt 命令（回溯）来获取应用程序崩溃时的堆栈跟踪。

【讨论】：

【解决方案2】：

我将这个问题通过电子邮件发送给undump 实用程序的创建者，以感谢他的专业知识，并得到以下回复：

正如那里的一些答案所述，可以包括通过设置 coredump_filter 的代码部分，但它不是 Linux 的默认设置（我不完全确定 BSD 变体和索拉里斯）。如果各个代码段都保存在原来的核心转储，为了创建新的，真的没有任何遗漏可执行。但是，它确实需要对原始版本进行一些更改核心文件（例如包括一个入口点并指向该入口指向将恢复 CPU 寄存器的代码）。如果核心文件是以这种方式修改它将成为一个可执行文件，你将能够运行它。不幸的是，一些州不会被保存，因此新的可执行文件将无法直接运行。打开文件、套接字、点等不会打开，甚至可能指向到其他 FD（这可能会导致各种奇怪的事情）。然而，对于大多数调试任务（例如运行）来说，这很可能就足够了来自 gdb 的小功能（这样您就不会得到“未运行可执行”的东西）。

【讨论】：

undump on Google Code 用于 i386（使用 gcc 标志 -m32 或端口到 64 位！）并且足以生成可以在 gdb 中运行的可执行文件，它会得到相同的结果段错误。它没有符号，但您可以使用 gdb 命令symbol-file 从原始二进制文件中获取符号。这使您可以调用函数并查看全局变量，但不能查看局部范围（堆栈）变量、符号或代码行。不过，我看不出有什么原因无法解决。
（CTAN 上还有一个更老的 undump，它以前用于创建 TeX 前端二进制文件。这具有历史意义，但现在已过时。）

【解决方案3】：

在较旧的 unix 变体中，默认情况下在核心转储中包含文本和数据，但它也以 a.out 格式而不是 ELF 格式给出。今天的默认行为（当然在 Linux 中，不是 100% 确定 BSD 变体、Solaris 等）是在没有文本部分的情况下以 ELF 格式进行核心转储，但可以更改该行为。
但是，在任何情况下都不能在没有帮助的情况下直接执行核心转储。原因是一个简单的核心文件缺少两件事。一个是入口点，另一个是将 CPU 状态恢复到转储发生时或之前的状态的代码（默认情况下也缺少文本部分）。
在 AIX 中曾经有一个名为 undump 的实用程序，但我不知道它发生了什么。它不存在于我所知道的任何标准 Linux 发行版中。正如上面提到的（@WumpusQ），也有一个类似的项目尝试在上面提到的 Linux 上 cmets，但是这个项目不完整并且不会将 CPU 状态恢复到原始状态。但是，在某些特定的调试情况下，它仍然足够好。
还值得一提的是，还有其他 ELF 格式的文件也不能执行，它们不是核心文件。比如对象文件（编译器输出）和.so（共享对象）文件。这些在运行以解析外部地址之前需要一个链接阶段。

【讨论】：

非常感谢您的清晰解释，关于 .o 和 .so 文件的观点是我没有想到的有效观点。我还从undump 实用程序的创建者那里得到了关于入口点等的类似答案，为了完整起见，我现在将其作为另一个答案发布。我接受了你的回答，但为了以防万一，现在暂时开放赏金。
“undump”概念的另一个大问题是您丢失了与崩溃时打开的文件描述符相关的所有状态。
@WumpusQ.Wumbley 是的，undump 的创建者在他的电子邮件中提到了这个问题，我已经发布了这个回复作为这个问题的另一个答案。
您可以使用 /proc//coredump_filter 更改在 Linux 上转储的部分（或为所有进程使用内核引导选项 coredump_filter）。见core(5)。