デバッグオプション-gはバイナリ実行可能ファイルをどのように変更しますか？
C/C++コードを記述する場合、バイナリ実行可能ファイルをデバッグするには、コンパイラ/リンカーでデバッグオプションを有効にする必要があります。 GCCの場合、オプションは-gです。デバッグオプションを有効にすると、バイナリ実行可能ファイルにどのような影響がありますか？デバッガー機能を許可する追加のデータがファイルに格納されていますか？
-gは、実行可能ファイルにシンボルテーブル情報を格納するようコンパイラーに指示します。とりわけ、これには以下が含まれます。
- シンボル名
- シンボルのタイプ情報
- シンボルが由来するファイルと行番号
デバッガーはこの情報を使用して、シンボルの意味のある名前を出力し、ソース内の特定の行に命令を関連付けます。
一部のコンパイラでは、-gを指定すると特定の最適化が無効になります。たとえば、明示的に-O [123]を指定しない限り、iccは-gを使用してデフォルトの最適化レベルを-O0に設定します。また、-O [123]を指定しても、スタックトレースを防止する最適化は引き続き無効になります（たとえば、スタックフレームからフレームポインターを削除します。これはパフォーマンスにわずかな影響しか与えません）。
一部のコンパイラでは、-gは最適化を無効にして、シンボルの出所を混乱させる可能性があります（命令の並べ替え、ループの展開、インライン化など）。最適化を使用してデバッグする場合は、gccで-g3を使用してこの問題を回避できます。インライン化された可能性のあるマクロ、展開、および関数に関する追加のデバッグ情報が含まれます。これにより、デバッガーとパフォーマンスツールは最適化されたコードを元のソースにマッピングできますが、最善の努力です。いくつかの最適化は実際にコードを混乱させます。
詳細については、 [〜＃〜] dwarf [〜＃〜] をご覧ください。元々はELF（Linuxおよび他のOSのバイナリ形式）に合わせて設計されたデバッグ形式です。
シンボルテーブルが実行可能ファイルに追加され、関数/変数名をデータの場所にマッピングするため、デバッガーは単なるポインターではなく意味のある情報を報告できます。これはプログラムの速度には影響せず、「strip」コマンドでシンボルテーブルを削除できます。
デバッグおよびシンボル情報に加えて
Google DWARF（ELFの開発者のジョーク）
デフォルトでは、デバッグが有効な場合、ほとんどのコンパイラ最適化はオフになっています。
。
しかし、最も重要な違い（私の意見では）
デバッグビルドのメモリは通常、デバッグを容易にするために、コンパイラ固有の値に初期化されます。リリースビルドでは、アプリケーションコードによって明示的に行われない限り、メモリは初期化されません。
詳細については、コンパイラのドキュメントを確認してください。
しかし、DevStudioの例は次のとおりです。
- 0xCDCDCDCDヒープに割り当てられていますが、初期化されていません
- 0xDDDDDDDDヒープメモリを解放しました。
- 0xFDFDFDFD「NoMansLand」フェンスは、ヒープメモリの境界に自動的に配置されます。上書きしないでください。上書きする場合は、おそらく配列の終わりから歩いていることになります。
- 0xCCCCCCCCスタックに割り当てられていますが、初期化されていません
-gは、変数名、関数名、行番号などのデバッグ情報を実行可能ファイルに追加します。これにより、gdbなどのデバッガーがコードを1行ずつステップ実行し、ブレークポイントを設定し、変数の値を検査できます。このため、-gを使用すると、実行可能ファイルのサイズが大きくなります。
また、gccでは-gを-Oフラグと一緒に使用して、最適化を有効にすることができます。最適化された実行可能ファイルのデバッグは、変数が最適化されるか、命令が異なる順序で実行される可能性があるため、非常に注意が必要です。一般的に、-gを使用する場合は、コードの処理速度が大幅に低下しますが、最適化をオフにすることをお勧めします。
これと一部重複しています question これは反対側からの問題をカバーしています。
ちょうど興味のある問題として、hexeditorをクラックして、-gで作成された実行可能ファイルとそうでないものを見ることができます。追加されたシンボルとものを見ることができます。アセンブリ（-S）も変更される可能性がありますが、わかりません。
一部のオペレーティングシステム（ z/OS など）は、デバッグシンボルを含む「サイドファイル」を生成します。これにより、追加情報で実行可能ファイルが肥大化するのを防ぐことができます。