コアダンプに関するウィキペディアのページには、
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コメントで a に言及しているので、おそらく上記の質問は次のようになるはずです:それ自体で実行できるようにコア ダンプを生成できますか?
古い UNIX バリアントでは、テキストとデータをコア ダンプに含めるのがデフォルトでしたが、ELF ではなく a.out 形式でも指定されていました。現在のデフォルトの動作 (Linux では確かに、BSD バリアント、Solaris などについては 100% 確実ではありません) は、コア ダンプをテキスト セクションなしで ELF 形式にすることですが、その動作は変更できます。
ただし、なんらかの助けがなければ、いかなる場合でもコア ダンプを直接実行することはできません。その理由は、単純なコア ファイルに欠けているものが 2 つあります。1 つはエントリ ポイントで、もう 1 つは CPU の状態をダンプが発生した時点またはその直前の状態に復元するためのコードです (デフォルトではテキスト セクションもありません)。
AIX には undump というユーティリティがありましたが、何が起こったのかわかりません。私が知っている標準の Linux ディストリビューションには存在しません。上記 (@WumpusQ) のように、上記のコメントで言及されている Linux 用の同様のプロジェクトも試みられていますが、このプロジェクトは完了しておらず、CPU の状態を元の状態に復元していません。ただし、一部の特定のデバッグ ケースでは、それでも十分です。
コア ファイルではない、実行できない ELF 形式のファイルが他にも存在することにも注意してください。オブジェクト ファイル (コンパイラ出力) や .so (共有オブジェクト) ファイルなど。これらは、外部アドレスを解決するために実行する前に、リンク段階が必要です。
ユーティリティの作成者に専門知識を求めてこの質問をメールで送信したundumpところ、次の返信がありました。
そこの回答のいくつかで述べたように、coredump_filter を設定することでコード セクションを含めることができますが、これは Linux のデフォルトではありません (BSD バリアントと Solaris については完全にはわかりません)。さまざまなコード セクションが元のコア ダンプに保存されている場合、新しい実行可能ファイルを作成するために必要なものは何もありません。ただし、元のコア ファイルにいくつかの変更を加える必要があります (エントリ ポイントを含め、そのエントリ ポイントを CPU レジスタを復元するコードにポイントするなど)。コア ファイルをこのように変更すると、実行可能ファイルになり、実行できるようになります。残念ながら、一部の状態は保存されないため、新しい実行可能ファイルを直接実行することはできません。ファイル、ソケット、ピップ、などは開かれず、他の FD を指している可能性さえあります (これはあらゆる種類の奇妙なことを引き起こす可能性があります)。ただし、gdb から小さな関数を実行するなどのほとんどのデバッグ タスクにはおそらく十分でしょう (「実行可能ファイルを実行していない」という問題が発生しないようにするため)。
他の人が言ったように、元のバイナリがないとコア ダンプ ファイルを実行できないと思います。
バイナリをデバッグすることに関心がある場合 (およびデバッグ シンボルが含まれている場合、つまり、削除されていない場合) を実行できますgdb binary core。
gdb 内では、btコマンド (backtrace) を使用して、アプリケーションがクラッシュしたときにスタック トレースを取得できます。