Shipping・シンボルファイル・PDB・デバッガ¶

一言で言うと¶

同じソースから「何を優先するか」別に複数の成果物を作り分けるのがビルド構成 (configuration)。最適化・チェック・デバッグ情報・ログの4軸の組み合わせです(最適化の中身は → 第6部)。

構成	最適化	assert/チェック	デバッグ情報	用途
Debug	なし(-O0//Od)	全部有効	フル	ロジックのステップ実行。ゲームによっては遊べない速度
Development	あり(-O2)	有効(assert・チートメニュー・プロファイラ計測)	あり	日常の開発・デバッグの主力。UEのDevelopmentがこれ
Release/Profile	あり	計測のみ残す	あり(外部保存)	性能計測(チェックのコストを排除した本番相当)
Shipping	最大+LTO	無効(クラッシュレポートのみ)	PDBは生成して手元に保管(同梱しない)	出荷物

2構成(Debug/Release)しかない標準的なCMake設定に対し、ゲームは「最適化ありでデバッグもしたい」需要が強く、中間構成を足すのが通例
構成ごとの分岐はマクロで: NDEBUG(標準: assert無効化)、自前の #if GAME_SHIPPING など。構成間で挙動が変わりすぎると「Shippingでだけ出るバグ」が増えるので、ゲームロジックの分岐は最小限に

コンパイラは「機械語のアドレス ⇔ ソースの行・変数名」の対応表=デバッグ情報を作れます。Windows/MSVCではPDBファイル(別ファイル)、GCC/Clangでは実行ファイル内蔵(-g)や分離(split-dwarf)。

最適化とデバッグ情報は独立: -O2 -g は普通(Development構成の実体)。最適化で変数が消える・行が飛ぶのは情報の限界であってPDBの故障ではない
Shippingの鉄則: PDBは必ず生成してビルドごとに保管(シンボルサーバー)。ユーザーのクラッシュダンプ(スタックのアドレス列)は、そのビルドのPDBがないと解読不能。「シンボル無しのクラッシュレポート=ただの16進数」
PDBを同梱・配布しない(リバースエンジニアリングが容易になる)

Visual Studioデバッガ(Windows/コンソールの主力)、LLDB(Mac/Clang系)、GDB(Linux/GCC系)
ブレークポイント・ステップ実行・ウォッチの基本に加え、ゲーム開発で価値が高い機能:
条件付きブレーク(enemyId == 42 のときだけ止まる)/ データブレークポイント(このアドレスに書き込んだら止まる——メモリ破壊犯の特定に絶大 → メモリバグ)
クラッシュダンプ(ミニダンプ)のポストモーテムデバッグ: ユーザー環境のクラッシュを、ダンプ+PDBで手元で再生
アタッチ: 起動済みのゲームプロセスに後から接続
「printfデバッグは恥」ではない——並行・タイミング系はログの方が有効なことも多い。両刀が正解

Unity/C#	C++
エディタ再生(Mono/JIT)	Debug/Development相当
Development Build チェックボックス	Development構成
IL2CPP + Release	Release/Shipping構成(このページの世界)
.pdb/.mdb(スクリプトデバッグ情報)	PDB(概念同一)
Cloud Diagnostics / Crashlytics	クラッシュダンプ+シンボルサーバー

Unityでは構成が2〜3個に見えるが、その下でIL2CPPが吐いたC++がこのページの構成でビルドされています。

「デバッグはエディタでやるもの」— C++ではShipping相当でだけ出るバグ(最適化・タイミング・アセット差)を追う技術(ダンプ解析)が必須スキル
「PDBはビルドの副産物」— Shippingでは成果物の一部(保管しないとサポート不能)
assertは「あると安心」ではなく構成戦略の一部——Debugで大量に入れ、Shippingで消えることで、開発中の検出力と出荷物の速度を両立する(→ 契約のassert)

samples/cmake_demo/ を -DCMAKE_BUILD_TYPE=Debug と Release でそれぞれビルドし、(a) 実行ファイルサイズ、(b) assertの有効/無効(NDEBUGの効果)を確認してください。