核心转储上的维基百科页面显示
在类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.Umbley在评论中提到了coredump_filter，也许上面的问题应该是：是否可以生成一个核心转储，使其可以自己执行？
在较旧的unix变体中，默认情况下在核心转储中包括文本和数据，但它也以.out格式提供，而不是ELF。今天的默认行为（在Linux中，当然不是100%确定BSD变体、Solaris等）是以ELF格式进行核心转储，不包含文本部分，但这种行为可以更改
但是，在任何情况下，如果没有一些帮助，都无法直接执行核心转储。原因是一个简单的核心文件缺少两件事。一个是入口点，另一个是将CPU状态恢复到转储发生时或转储发生之前的状态的代码（默认情况下，文本部分也会丢失）
在AIX中曾经有一个名为undump的实用程序，但我不知道它发生了什么。据我所知，它在任何标准Linux发行版中都不存在。正如上面提到的（@WumpusQ），在上面的评论中也提到了一个类似的Linux项目，但这个项目并不完整，也没有将CPU状态恢复到原始状态。然而，在某些特定的调试情况下，它仍然足够好
还值得一提的是，存在其他不能执行的ELF格式的文件，这些文件不是核心文件。例如对象文件（编译器输出）和.so（共享对象）文件。这些程序在运行以解析外部地址之前需要一个链接阶段。
我通过电子邮件向undump实用程序的创建者询问了这个问题的专业知识，并得到了以下回复：
正如一些答案中所提到的，可以包括代码部分通过设置coredump_filter，但它不是Linux的默认值（我不完全确定BSD变体和Solaris）。如果各种代码部分保存在原始文件中核心转储，为了创建新的可执行文件。然而，它确实需要对原始版本进行一些更改核心文件（例如包括一个入口点并指向该入口指向将恢复CPU寄存器的代码）。如果核心文件以这种方式修改后，它将成为一个可执行文件，您将能够然而，不幸的是，一些州不会将被保存，因此新的可执行文件将无法直接运行。打开文件、套接字、pip等不会打开，甚至可能指向其他FDs（这可能会引起各种奇怪的事情）。然而对于大多数调试任务（如运行gdb中的小函数（这样就不会得到"不运行可执行文件）。
正如其他人所说，我认为如果没有原始二进制文件，就无法执行核心转储文件。
如果您有兴趣调试二进制文件（它包含调试符号，换句话说，它没有被剥离），那么您可以运行gdb binary core。
在gdb中，当应用程序崩溃时，可以使用bt命令（backtrace）来获取堆栈跟踪。