こんにちは！開発環境アーキテクトの先輩です。
今回は、C言語開発において避けて通れない「バイナリサイズの極限削減」についてお話しします。
「たかが数キロバイトの容量でしょ？」なんて侮っていませんか？ IoTや組み込み機器の世界では、Flashメモリの数キロバイトが製品の生死を分ける死活問題です。また、クラウドネイティブなコンテナイメージの軽量化や、エッジデバイスでのロード時間短縮においても、無駄なコードのないシュッとしたバイナリは、開発者の「品格」そのものと言えます。
今回は、GCCが内部でどのようにコードを料理しているのかという裏側の仕組み（アーキテクチャ）を紐解きながら、初心者の方でも今日から即座に使える実践的なサイズ最適化の技術を、優しく、そして徹底的に解説していきますね。
これをマスターすれば、あなたのビルドするバイナリは見違えるほどスリムになり、パフォーマンスも信頼性も劇的に向上しますよ。さあ、一緒に深淵なる低レイヤの世界へ飛び込みましょう！
—
1. なぜバイナリは膨らむのか？（GCCとリンカの裏側）
私たちが普段何気なく書く `printf(“Hello, World!\n”);` というたった1行のコード。GCCでコンパイルしてそのまま実行ファイルを作ると、驚くことに数キロバイト、場合によっては数十キロバイトもの大きさになります。
「俺はたった10文字しか書いていないのに、なぜだ！？」
そう思ったことはありませんか？ ここには、コンパイラ（GCC）とリンカ（GNU LDなど）の「親切心」が隠されています。
デフォルトのビルドでは、以下のような「余計なお世話（だが標準規格では必要なもの）」がデフォルトで組み込まれます。
- デバッグシンボル: 「後でGDBでデバッグできるように」と、変数名や関数名、ソースコードの行番号情報がそのままバイナリ内に残されます。
- 未使用の関数やデータ: 標準ライブラリ（glibcなど）の巨大なアーカイブファイルから、リンク時に「もしかしたら使うかもしれない」という関数群がごっそり引き抜かれて実行ファイルに結合されます。
- 標準の初期化・終了ルーチン: `main` 関数が呼ばれる前に行われるランタイムの初期化コード（`crt0.o` など）が含まれます。
これらを綺麗に削ぎ落とし、本当に必要な機械語命令（Machine Instructions）だけを残す作業が、今回のテーマである「サイズ最適化と不要シンボル削除」です。
—
2. 基礎のセットアップと検証用コードの準備
まずは、今回の実験場となる環境を整えましょう。Linux（UbuntuやDebian系）を前提に話を進めますが、macOSのClangでも基本思想は同じです。
必要なツールのインストール
以下のコマンドで、GCCとバイナリ解析・操作ツール（binutils）を確実にインストールしておきます。
パッケージリストを更新し、ビルド必須ツールとバイナリ操作ツールを導入する
sudo apt-get update && sudo apt-get install -y build-essential binutils
- `build-essential`: GCC、G++、Make、そしてリンカが含まれる基本パッケージです。
- `binutils`: `strip` や `size`, `objdump` といった、バイナリの内部構造を剥き出しにして外科手術を行うための伝説的なツール群が含まれています。
究極の「Hello, World!」を書く
次に、検証用のCソースコードを作成します。あえて極限までシンプルにした `main.c` を用意してください。
// main.c
// 極限まで無駄を削ぎ落としたエントリーポイント
include
int main(void) {
// printfは内部で重いロケール処理やバッファリングを持つため使わず、
// システムコールに直結するwrite関数を直接叩いてオーバーヘッドを消す
write(1, “Hello, World!\n”, 14);
return 0;
}
> 💡 先輩のワンポイントアドバイス:
> 通常の初心者は `printf` を使いがちですが、`printf` は内部で文字列表現のフォーマット解析やOSへのバッファリングを行うため、それだけで数キロバイトのコードがリンクされてしまいます。組み込みや超軽量化の世界では、OSのシステムコールに直結する `write` などの低水準APIを使うのが定石です。
—
3. バイナリサイズ削減の三種の神器
ここからが本題です。GCCとbinutilsが誇る「3つの最強の武器」を順番に適用し、バイナリが劇的に小さくなっていく過程をその目で目撃してください。
武器その1: 最適化フラグ `-Os` とデバッグ情報の排除
まずは、コンパイル時に `-Os`（Optimize for size）を指定します。一般的な `-O2` や `-O3` は「実行速度の高速化」を最優先するため、コードのインライン展開（関数の中身を呼び出し元にそのまま貼り付けること）によって逆にコードサイズが膨らむことがあります。`-Os` は、コードサイズを膨らませない範囲で最大限の最適化を行うフラグです。
さらに、コンパイル時に `-s` オプションを渡すか、ビルド後に `-g`（デバッグ情報）を排除します。
ステップ1: 標準的なビルド（比較用）
gcc main.c -o main_default
ステップ2: サイズ最適化(-Os)と不要なシンボルのコンパイル時除外
gcc -Os -s main.c -o main_optimized
それぞれのサイズを確認してみる
ls -lh main_default main_optimized
この時点で、バイナリサイズがガクッと小さくなっているのが確認できるはずです。
武器その2: `strip` コマンドによる外科手術
コンパイルが終わったバイナリには、まだOSが実行する際には1ミリも必要のない「シンボルテーブル（関数名やグローバル変数名の対応表）」が残されています。これを綺麗に削ぎ落とすのが `strip` コマンドです。
元の最適化済みバイナリをコピー
cp main_optimized main_stripped
stripコマンドでデバッグ情報やシンボルテーブルを完全に消去する
–strip-all は、ローカルシンボルだけでなく外部公開シンボルもすべて消し去る最強のオプション
strip –strip-all main_stripped
サイズを比較する
ls -lh main_optimized main_stripped
- `main_optimized`: サイズ最適化済みだがシンボルが残っている
- `main_stripped`: `strip` により不要なメタデータが完全に剥ぎ取られた状態
この `strip` をかけるだけで、実行ファイルのサイズはさらに数キロバイト削られます。小さなプログラムであれば、これだけで元のサイズの半分以下になることも珍しくありません。
武器その3: リンク時最適化（LTO: Link Time Optimization）と関数・データセクションの分離
さあ、ここからがアーキテクチャの真骨頂です。現代のGCCには、複数のソースファイル（あるいは標準ライブラリ）をまたいで最適化を行う LTO (Link Time Optimization) という強力な機能があります。
さらに、通常GCCは「オブジェクトファイル単位」でしか不要なコードを捨てられませんが、コンパイラフラグで「関数ごと」「データごと」に独立したセクション（部屋）に分割し、リンカに「使われていない部屋は丸ごとゴミ箱に捨てろ」と命令することができます。
以下の究極のコンパイルコマンドを実行してみてください。
究極のサイズ削減コンパイル
gcc -Os -flto -ffunction-sections -fdata-sections main.c -Wl,–gc-sections -o main_ultimate
呪文のようなフラグの解説:
- `-flto` (Link Time Optimization): リンク時にコード全体を俯瞰し、使われていない静的関数などを徹底的に消去します。
- `-ffunction-sections` / `-fdata-sections`: ソースコード内のすべての関数や変数を、それぞれ独立したセクション（孤立した小部屋）としてコンパイルします。
- `-Wl,–gc-sections`: リンカ（ld）に対し、「どのセクションからも参照されていない（使われていない）孤立した小部屋は、最終的なバイナリから完全に削除せよ（Garbage Collection）」と指示します。
—
4. 実際のサイズ変化を検証してみよう
それでは、ここまで作成したバイナリたちのサイズを `size` コマンドや `ls` コマンドで厳密に比較してみましょう。
すべての成果物のファイルサイズを一覧表示
ls -la main_
実行結果のイメージ（例）:
-rwxr-xr-x 1 user user 16120 May 20 10:00 main_default (デフォルト)
-rwxr-xr-x 1 user user 15992 May 20 10:00 main_optimized (-Os + -s)
-rwxr-xr-x 1 user user 6352 May 20 10:00 main_stripped (strip適用)
-rwxr-xr-x 1 user user 6144 May 20 10:00 main_ultimate (LTO + セクション削除)
見事です！ デフォルトでは16KBを超えていたバイナリが、最終的な「究極の構成」では6KB台まで縮小されました。約60%以上の削減率を叩き出しています。
また、`size` コマンドを使うことで、セクションごとの内訳を細かく確認できます。
size main_default main_ultimate
- `text`: 実行される機械語命令のサイズ
- `data`: 初期化済み大域変数のサイズ
- `bss`: 未初期化大域変数のサイズ
ここを監視しながらビルド調整を行うのが、プロの組み込みエンジニアの流儀です。
—
5. 先輩からの実践的なアドバイスと注意点
「よーし、じゃあ明日からすべてのプロジェクトで `-flto -Wl,–gc-sections` と `strip` をガンガン使おう！」
……ちょっと待ってください。ここで先輩から現場の教訓をいくつかお伝えしておきます。
1. 動的リンクと静的リンクの意識:
今回行った最適化は、主に「静的リンク（Static Linking）」や、スタンドアロンで動くバイナリにおいて絶大な効果を発揮します。共有ライブラリ（`.so` や `.dll`）を多用する環境では、シンボルを消しすぎると外部から呼び出せなくなってクラッシュ（シンボル解決エラー）を起こす原因になります。
2. 動的ロードやプラグイン機構への影響:
`strip –strip-all` は、プログラムが動的に別の関数をロードする仕組み（`dlopen` やコールバック関数など）で使用されるシンボル名まで消し去ってしまうことがあります。「動かした瞬間にセグメンテーション違反で落ちる」という謎のバグに直面したときは、大抵シンボルを削りすぎたことが原因です。
3. デバッグの難易度:
サイズを極限まで削ったバイナリは、GDBでデバッグしようとしても関数名や変数名が失われているため、メモリアドレスの海を彷徨うことになります。デバッグビルド（Development）とリリース・プロダクションビルド（Production）で、MakefileやCMakeなどでフラグを明確に切り替える仕組みを必ず構築してください。
—
まとめ
今回は、GCCとClangを用いたC言語のバイナリサイズ削減について、その内部メカニズムから具体的なコマンドまで深く掘り下げて解説しました。
- `-Os` でサイズ優先のコンパイルを行う
- `-ffunction-sections` と `-Wl,–gc-sections` で使われていないコードの断片をゴミ箱に捨てる
- `-flto` でファイル間を跨いだ広範囲な最適化をかける
- `strip –strip-all` で不要なメタデータを剥ぎ取る
この一連のパイプラインをあなたの開発フロー（MakefileやCMake、CI/CD環境）に組み込むだけで、生成されるバイナリは見違えるほど軽快になり、リソースの限られた環境でも堂々と胸を張って動かせるようになります。
これをマスターしたあなたなら、もう容量制限に怯える必要はありません。
毎日のコーディングとビルドが、さらにエキサイティングで楽しいものになりますように！ 次回の解説もお楽しみに。