共有システムライブラリの正確なデバッグシンボルを持たないリモートポストモルテムコリダンプ分析

Question

通常、この問題をどのように回避しますか？ Computer1のLIBCコード（システム共有ライブラリ）内でスレッドがクラッシュし、CoreDumpが生成されると想像してください。しかし、このCoreDumpが分析されるComputer2には、LIBCの異なるバージョンがある場合があります。

それで：

1. リモートコンピューターに同じ共有ライブラリを持つことがどれほど重要ですか？ GDBは、conputer2にまったく同じバージョンのLIBCを持たずにStackTraceを正しく再構築しますか？

2. LIBCのデバッグシンボルを正しいデバッグシンボルを持つことがどれほど重要ですか？ GDBは、Computer2にまったく同じデバッグシンボルを持たずにStackTraceを正しく再構築しますか？

3. そして、共有システムライブラリのこのデバッグシンボルの不一致の問題を回避する「正しい」方法は何ですか？私にとって、この問題をエレガントな方法で解決する解決策は1つないようですか？たぶん誰かが彼の経験を共有することができますか？

Answer 1

1. 場合によります。などの一部のプロセッサで x86_64, 、 正しい リクインド記述子 GDBがスタックを適切にリラックスするには必要です。このようなマシンでは、非一致するLIBCでCoreDumpを分析すると、完全なゴミが生成される可能性があります。

2. スタックトレースを取得するためにLIBCのデバッグシンボルは必要ありません。デバッグシンボルなしでファイル番号とライン番号を取得しませんが、正しい関数名を取得する必要があります（インラインが行われた場合を除く）。

3. あなたの質問の前提は間違っています - デバッグ記号はこれとは何の関係もありません。 coredumpがC1で生成された場合、C2でCoreDumpを分析する「正しい」方法は、C1のライブラリのコピーを持つことです（例： /tmp/C1/lib/...）そして、GDBがC2のインストールされている代わりにそのコピーを使用するように指示します 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

（私はウェブ上でこれへの参照を見つけようとしましたが、そうしませんでした）。

巻き上げ記述子とは何ですか？

フレームポインターなしでコードがコンパイルされている場合は、unvind記述子が必要です（最適化されたモードでx86_64のデフォルト）。そのようなコードはそうです いいえ ％RBPレジスタを保存するため、GDBは現在のフレームから発信者フレームへの「ステップバック」方法を指示する必要があります（このプロセスはスタック巻き戻しとしても知られています）。

C1のLIBC.SOがコアに含まれていないのはなぜですか？

コアファイルには、通常、プログラムアドレス空間の書き込み可能なセグメントの内容のみが含まれています。通常、読み取り専用セグメント（実行可能コードとリラックス記述子が存在する場合）は通常必要ありません。libc.soから直接読むことができます。

C2のC1のコアを分析するときにこれが機能しないことを除いて！

一部の（すべてではない）オペレーティングシステムにより、OSが読み取り専用マッピングをダンプする「完全なCoreDumps」を構成することができます。