#includeファイルを（私が書いたものではなく）記録するという厄介な問題をデバッグしています。私のプログラムではクラッシュします。つまり、workingとbrokenがあり、C（++）include文は1つだけ変更されています。私が使っているライブラリの中には、デバッグ情報を持っていないものがあります。GDBを使用してC +アセンブリプログラムトレースを出力するにはどうすればよいですか？
私がしたいのは、プログラム実行のために実行されるC++のすべての行と、2つの出力を比較することができるような形式のテキストファイルでは利用できないx86命令を出力することです。間違えた。
これはGDBでも簡単にできますか？
各バージョンの前処理された出力の違いを確認できます。例：
gcc -dD -E a.cc -o a.pre
gcc -dD -E b.cc -o b.pre
diff -u a.pre b.pre
さまざまな "-d"設定を試して、より冗長で簡潔にすることができます。おそらく、リストの違いの何かが明らかになるでしょう。これは通常、インクルードファイルに応じてサイズを変更する構造体のようなものです。
実際に命令ごとまたはライントレースを混乱させたい場合は、おそらくvalgrindを使用してパスの分岐先を確認することができますが、あなたは苦痛の世界にいると思います。実際にvalgrindがあなたのバグを見つけて、それからあなたが知りませんでした:)私はこの問題が単なる構造体や他のデータサイズの違いだと思います。あなたは気にする必要はありません。
gdbを使って行のトレースを自動化することができます。それはかなり痛いでしょう。基本的には、クラッシュするまで「n」（次の行）を繰り返し実行するようにスクリプトを作成し、ログを確認する必要があります。 "b main"をスクリプト化してから "run"し、それを行う無限の "n"をスクリプトできるならば。おそらくそれを行う組み込みのコマンドがありますが、私はそれを認識していません。
GDBではこれを行うことはできません。しかし、プロフィールが役立つでしょうか？あなたはgccでコンパイルしていますか？ -pと-pfコマンドを見て、私はそれらが役に立つかもしれないと思う。
gdbプロンプトでdisassembleコマンドを実行すると、停止している現在の機能が逆アセンブルされますが、実行パス全体を出力することはできないと考えられます。
あなたにはどのライブラリが含まれていますか？オープンソースの場合は、デバッグシンボルを有効にして再コンパイルできます。また、Linuxを使用している場合、ほとんどのディストリビューションに共通ライブラリのパッケージのバージョンが-dbgになります。
構造体などの '＃if' /'＃else'バリエーションだけでなく、静的な初期化がバグかもしれません。依存関係がある場合、 '＃include'はそれに含まれる他のものの順序を変更し、クラッシュを引き起こすかもしれません。あるいは、 '#include'ファイルは、初期化に失敗した静的オブジェクトを追加するかもしれません。 'gcc -E'出力はこれらの問題の調査を開始するのにも良い方法です。 '#include'が最後に置かれた（他のインクルードの順番が変更されないように）ためにdiffノイズが最小限に抑えられるかもしれません。 –
diffスパムを減らすためにいくつかの組み合わせで再生しました。これはうまくいくかもしれません：gcc -E a.cc -o a.pre; ...; diff -uw -I '^＃' a.pre b.pre –
提案していただきありがとうございます。問題は、ヘッダーファイル（2レベル深い！）は#pragma pack（1）に対応する#pragma pack（pop）がなく、最後にSTLライブラリがパックされていることになりました。 。影響を受ける構造体に対してプラグマを削除し、__attribute __（（packed））に切り替えると、この問題が解決されました。プログラムをクラッシュさせないようにしてから、ヘッダーの問題であることが分かったら、各レベルに含まれるヘッダーファイルに対してBFS検索を実行するまで、これを見つけ出しました。 – Mike