場合によります。などの一部のプロセッサでは、GDBがスタックを適切にアンワインドするにはx86_64
、正しいアンワインド記述子が必要です。このようなマシンでは、一致しないlibcを使用してコアダンプを分析すると、完全なガベージが生成される可能性があります。
スタックトレースを取得するためにlibcのデバッグシンボルは必要ありません。デバッグシンボルがないとファイル番号と行番号を取得できませんが、正しい関数名を取得する必要があります(インライン化が行われている場合を除く)。
あなたの質問の前提は間違っています-デバッグシンボルはこれとは何の関係もありません。C1でコアダンプが生成されたときにC2でコアダンプを分析する「正しい」方法は、C1のライブラリのコピー(たとえば)を用意し、C2がインストールされて/tmp/C1/lib/...
いる代わりにそのコピーを使用するようにGDBに指示することです。libc
(gdb) set solib-absolute-prefix /tmp/C1
指図。
注:コアをGDBにロードする前に、上記の設定が有効になっている必要があります。これ:
gdb exe core
(gdb) set solib-absolute-prefix /tmp/C1
動作しません(設定が有効になる前にコアが読み取られます)。
正しい方法は次のとおりです。
gdb exe
(gdb) set solib-absolute-prefix /tmp/C1
(gdb) core core
(私はウェブ上でこれへの参照を見つけようとしましたが、しませんでした)。
アンワインド記述子とは何ですか?
コードがフレームポインタなしでコンパイルされる場合は、アンワインド記述子が必要です(最適化モードでのx86_64のデフォルト)。このようなコードは%rbpレジスタを保存しないため、GDBに現在のフレームから呼び出し元のフレームに「ステップバック」する方法を指示する必要があります(このプロセスはスタックアンワインドとも呼ばれます)。
C1のlibc.soがコアに含まれていないのはなぜですか?
コアファイルには通常、プログラムアドレス空間の書き込み可能なセグメントの内容のみが含まれています。読み取り専用セグメント(実行可能コードとアンワインド記述子が存在する場所)は通常必要ありません。ディスク上のlibc.soから直接読み取ることができます。
ただし、C2でC1のコアを分析する場合は、これは機能しません。
一部の(すべてではない)オペレーティングシステムでは、「完全なコアダンプ」を構成できます。この場合、OSは読み取り専用のマッピングもダンプするため、任意のマシンでコアを分析できます。