gcc を使用して同じコードを別の時点でビルドすると、結果のバイナリの内容が異なります。わかりました、私はそれについてワイルドではありませんが、それはそれです.
しかし、最近、同じバージョンの gcc でビルドされた同じコードが、以前のビルドとは異なるサイズ (約 1900 バイト) のバイナリを生成する状況に遭遇しました。
これらの状況のいずれかを引き起こしている可能性があるものを誰か知っていますか? これはある種のELFの問題ですか？バイナリの内容をダンプして正確に何が違うのかを確認するために使用できるツールは (ldd 以外に) ありますか?
前もって感謝します。
少なくとも満足のいくように物事を整理することができたので、見つけたものを伝えたいと思いました。
readelf を使用して (readelf -a -W )、両方のビルドの内容をリストしたレポートを作成し、それらを比較しました (Beyond Compare を使用)。これは、いくつかの余分なシンボルがブースト ライブラリから取り込まれていることを示していました。
見よ、私たちは実際には依存ライブラリの異なるバージョンに対して構築していましたが、それを認識していませんでした. この場合、害はありませんが、実行可能ファイルに何が入っているかを知っておくとよいでしょう。
思慮深い回答をありがとうございました。
objdumpおそらく、バイナリの内容をダンプするために探しているプログラムです。
objdump -hセクションとそのサイズが表示されるので、サイズの変更が発生している場所を確認し、さらにドリルダウンしてその理由を確認できるはずです。
再現可能な例が役立ちます：
これは以前に尋ねられたようなもので、答えは、コンパイラの内部状態がコンパイラの実行ごとに異なる可能性があり、その結果、異なるコードが出力され、サイズが異なる可能性があるというものです。
DEC VMS コンパイラもこれを行っていました。その理由は、オプティマイザーがより多くの空き RAM を使用するほど、より良い仕事をすることができるからです。コンパイルするたびにまったく同じ量の空き RAM を使用できるようにすることは、明らかに非常に困難です。
当時、これに愕然とした人がいたことを覚えています。これは特に、結果のバイナリを比較してソースの変更をチェックするのが好きな人に当てはまりました。その時も今も私のアドバイスは、それを乗り越えることです。「比較」できるソース。バイナリの場合、唯一の保証は、同じソース ファイルからコンパイルされた両方の実行可能ファイルが、指定したとおりに実行されることです。
コンパイラに加えて、リンク先の標準ライブラリをチェックする必要があります。バージョンを確認し、変更されていないことを確認します。
他の点では同一のビルド間のサイズの違いの考えられる理由の 1 つは、バイナリに可変サイズの情報が格納される可能性があることです。いくつかの例：
__FILE__コンパイラは、デバッグ情報のために、またはマクロの使用のために、コンパイルで呼び出されたファイルに関するパス/名前情報を入れている可能性があります。これらのいずれとも関係のない独自の目的でこれを行う可能性があります。ディレクトリ構造がわずかに異なる別のマシンでビルドが行われた場合、バイナリの違いが原因である可能性があります。Neil Butterworth が指摘したように、これらのことはビルド マシンの状態の違いに要約されます。