私はデバッグにコアダンプを使用しています。 gdbでは、コアダンプだけでなく実行可能ファイルも提供する必要があります。なぜこれですか？コアダンプにプロセスで使用されるすべてのメモリが含まれている場合、コアダンプに実行可能ファイルが含まれていますか？完全なexeがメモリにロードされるという保証がない場合（単一の実行ファイルは通常それほど大きくありません）、最終的にコアダンプに関連するメモリがすべて含まれていない可能性があります。シンボルに関するものですか（おそらくメモリに正しくロードされていない可能性があります）？
ベストアンサー1
コアダンプはプログラムのメモリスペースをダンプしたものに過ぎず、すべてがどこにあるのか知っていればそれを使うことができます。
実行可能ファイルを使用する理由は、メモリ（つまりコアファイル）の場所（論理アドレスの側面）を説明するためです。
このコマンドを使用すると、objdump調査中の実行可能オブジェクトのメタデータがダンプされます。 a.outという実行可能オブジェクトを例に挙げてみましょう。
objdump -h a.outヘッダー情報のみをダンプするには、次のセクションが表示されます。。データまたは.bssまたは。テキスト（もっとあります）。これは、オブジェクト内のさまざまな部分を見つけることができる場所、プロセスアドレス空間でロードする必要がある場所、特定の部分（たとえば、.data .text）に対してロードする必要がある場所をカーネルローダーに通知します。 （.bssセクションには、ファイル内のデータは含まれていませんが、初期化されていないデータのためにプロセスによって予約されたメモリ量を表し、ゼロで埋められます。）
実行可能オブジェクトファイルのレイアウトは標準ELFに従います。
objdump -x a.out- すべてを捨てる
実行可能オブジェクトにまだシンボルテーブルが含まれている場合（削除されておらず、ACソースのコンパイルを想定してデバッグビルドを作成するman stripために使用されている場合）、たとえば変数がある場合は、シンボル名で重要な内容を確認できます。 /バッファ名は次のとおりです。-ggcc入力ラインソースコードでこの名前を使用してコンテンツgdbを表示できます。つまり、gdbプログラム初期化データセグメントからのオフセットを知っています。入力ラインこの変数の開始と長さです。
追加読書第1条、 第2条、実用的な内容はもちろんです。実行可能および接続形式（ELF）仕様。
以下の@mirabilosコメント以降に更新されました。
しかし、以下のようにシンボルテーブルを使用すると、
$ gdb --batch -s a.out -c core -q -ex "x buf1"
生産
0x601060 <buf1>: 0x72617453
すると、シンボルテーブルを使わずにアドレスを直接確認せず、
$ gdb --batch -c core -q -ex "x 0x601060"
生産
0x601060: 0x72617453
2番目のコマンドでは、シンボルテーブルを使用せずに直接メモリを確認しました。
また、@user580082の回答に追加の説明が追加され、投票することがわかります。