こんにちは！日々のコーディング、本当にお疲れ様です。
突然ですが、みなさんはC/C++でコードを書いているとき、「自分たちのプロジェクト特有のルールや、絶対にやってほしくないアンチパターンを、コンパイラが自動でバシッと弾いてくれたらなぁ……」と思ったことはありませんか？あるいは、「特定の重い関数を呼び出している箇所を、コンパイル時に勝手に最適化された別関数へすり替えてくれたら最高なのに……」と考えたことはないでしょうか。
一般的な静的解析ツールを使うのも手ですが、ルールを厳密にカスタマイズしようとすると限界があったり、ビルドプロセスとは別個にツールを走らせる手間が増えたりします。
そこで登場するのが、「GCCプラグイン開発」という魔法です。
今回は、Windows上のデファクトスタンダードな開発環境である MSYS2 / MinGW-w64 の世界を舞台に、コンパイラの内臓へ直接ダイブし、自分だけの「カスタム警告」や「コード変換パス」をねじ込む方法を、優しく丁寧に解説していきます。
この扉を開ければ、あなたは単なる「コンパイラの使い手」から、「コンパイラを支配するアーキテクト」へと進化できます。さあ、一緒に深淵なるコンパイラ拡張の世界へ足を踏み入れましょう！
—
1. なぜ MinGW-w64 / MSYS2 なのか？コンパイラ内部の仕組みを知る
多くのWindows開発者は、Visual Studio（MSVC）を好んで使います。MSVCも素晴らしいIDEですが、コンパイラ自体のオープンな拡張API（プラグイン機構）は非公開であり、独自のパスを挿入するのは容易ではありません。
一方、GCC（GNU Compiler Collection）は、その内部構造が非常にモジュール化されており、バージョン 4.5 以降、プラグイン機構（GCC Plugin API）が正式にサポートされています。これにより、GCC自体のソースコードを書き換えることなく、共有ライブラリ（`.dll` / `.so`）の形で「独自の最適化パス」や「独自の構文チェック」をコンパイルのパイプラインに動的に差し込むことができるのです。
そして、Windows環境でこのGCCプラグインを開発・実行する上で、もっとも洗練されたプラットフォームが MSYS2 です。Linuxのパッケージマネージャ（`pacman`）の利便性をそのままWindowsに持ち込み、最新の MinGW-w64 ツールチェイン（GCC）を手軽に構築できるため、プラグイン開発に必要なヘッダファイルや開発ライブラリも一発で揃います。
—
2. 開発環境のセットアップ：MSYS2とプラグイン開発用ヘッダの導入
まずは、MinGW-w64環境でGCCプラグインをビルドするための基礎固めをします。MSYS2がすでにインストールされている前提で話を進めますが、まだの方は公式ページからシェルを立ち上げてください。
プラグイン開発では、GCCの内部構造（GIMPLE表現やTree構造など）を定義したヘッダファイル群が必要になります。これらは通常のコンパイルには使われないため、開発パッケージを追加でインストールする必要があります。
手順1: 必要なパッケージのインストール
MSYS2のターミナル（通常は `UCRT64` 環境）を開き、以下のコマンドを実行します。
パッケージデータベースを同期し、基本ツールチェインとGCCプラグイン開発用パッケージをインストールする
pacman -Syu
pacman -S –needed base-devel mingw-w64-ucrt-x86_64-toolchain mingw-w64-ucrt-x86_64-gcc-libs
> 先輩からのアドバイス
> 実はMinGW-w64の公式GCCパッケージには、プラグイン開発に必須のヘッダやインポートライブラリが含まれていない場合があります。もしコンパイル時に `gcc-plugin.h` が見つからないというエラーに直面した場合は、MSYS2の環境に合わせて適切な開発用パッケージが導入されているか確認してください。
—
3. 実践！「危険な関数」を検知する独自警告プラグインの作成
それでは、今回のメインディッシュです。「特定の関数（例えば、危ういとされる `strcpy` など）がコード内に使われていたら、コンパイル時に独自の警告をブチ込む」という実用的なプラグインをC言語で自作してみましょう。
GCCプラグインは、GCCがロードする共有ライブラリとして作成します。
プラグインのソースコード：`my_security_plugin.c`
以下のコードを任意のディレクトリ（例: `~/plugin_work/`）に作成してください。
include
include “gcc-plugin.h”
include “plugin-version.h”
include “tree.h”
include “basic-block.h”
include “function.h”
include “gimple.h”
include “gimple-iterator.h”
include “tree-pass.h”
// GCCのライセンス要件を満たすための必須マクロ
int plugin_is_GPL_compatible;
// 1. パスの挙動を定義する構造体（今回はGIMPLE表現を走査するパス）
const struct pass_data my_security_pass_data = {
.type = GIMPLE_PASS,
.name = “my_security_check”,
.optinfo_flags = OPTGROUP_NONE,
.tv_id = TV_NONE,
.properties_required = PROP_gimple_any,
.properties_provided = 0,
.properties_destroyed = 0,
.todo_flags_start = 0,
.todo_flags_finish = 0,
};
// 2. パスの実体を定義
struct my_security_pass {
struct gimple_opt_pass pass;
};
// 3. パスの実行処理（コンパイル中の各関数ごとに呼ばれる）
unsigned int my_security_execute(struct function fun) {
gimple_stmt_iterator gsi;
basic_block bb;
// 現在処理している関数の名前を取得
const char func_name = function_name(fun);
// printf(“Analyzing function: %s\n”, func_name); // デバッグ用
// 関数内のすべての基本ブロック（Basic Block）を走査
FOR_EACH_BB_FN(bb, fun) {
// 基本ブロック内のすべての文（Statement / GIMPLE）を走査
for (gsi = gsi_start_bb(bb); !gsi_end_p(gsi); gsi_next(&gsi)) {
gimple stmt = gsi_stmt(gsi);
// 文が「関数呼び出し（Call）」であるかを判定
if (is_gimple_call(stmt)) {
tree fndecl = gimple_call_fndecl(stmt);
if (fndecl) {
const char callee_name = IDENTIFIER_POINTER(DECL_NAME(fndecl));
// もし呼び出されている関数が “strcpy” だったら警告を出す！
if (callee_name && __builtin_strcmp(callee_name, “strcpy”) == 0) {
// GCCの診断エンジンを使って、ソースコード上の位置情報を伴った警告を出力
warning_at(gimple_location(stmt), 0,
“【セキュリティ警告】危険な関数 ‘strcpy’ が検出されました！代わりに ‘strncpy’ を使ってください。”);
}
}
}
}
}
return 0;
}
// パスインスタンスの構築
struct my_security_pass my_security_pass_inst = {
.pass = {
.pub = {
.type = GIMPLE_PASS,
.name = my_security_pass_data.name,
.optinfo_flags = my_security_pass_data.optinfo_flags,
.tv_id = my_security_pass_data.tv_id,
.properties_required = my_security_pass_data.properties_required,
.properties_provided = my_security_pass_data.properties_provided,
.properties_destroyed = my_security_pass_data.properties_destroyed,
.todo_flags_start = my_security_pass_data.todo_flags_start,
.todo_flags_finish = my_security_pass_data.todo_flags_finish,
},
.execute = my_security_execute,
}
};
// 4. プラグインのエントリポイント（GCCが最初にロードしたときに呼ばれる）
int plugin_init(struct plugin_name_args plugin_info, struct plugin_gcc_version version) {
// バージョンの一致確認（GCCの内部APIはバージョンごとに変わるため極めて重要）
if (!plugin_default_version_check(version, &gcc_version)) {
fprintf(stderr, “エラー: GCCのバージョンが一致しません。\n”);
return 1;
}
// パスを挿入する場所を指定する設定構造体
struct register_pass_info pass_info;
pass_info.pass = &my_security_pass_inst.pass.pub;
pass_info.reference_pass_name = “ssa”; // SSA最適化パスの直前に挿入
pass_info.ref_pass_instance_number = 1;
pass_info.pos_op = PASS_POS_INSERT_BEFORE;
// GCCのプラグインイベントにパス登録をフックする
register_callback(plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info);
printf(“>>> 成功: 自作セキュリティプラグイン ‘my_security_check’ がロードされました。\n”);
return 0;
}
このコードの何がスゴいのか？
ここで私たちは、GCCの内部で使われる中間表現 GIMPLE（ジムプル） を直接覗き見ています。ソースコードがパースされ、最適化される手前の段階で「どの関数がどこから呼ばれているか（`gimple_call_fndecl`）」を完全に追跡し、通常の構文解析器では検知しにくい文脈依存のルールすら、自由自在にコンパイルエラーや警告に変えることができるのです。
—
4. プラグインのコンパイルと動作確認
作成したC言語のソースコードを、MinGW-w64のGCCを使って共有ライブラリ（`.dll`）としてコンパイルします。
プラグイン自体のビルドコマンド
MSYS2のターミナルで、以下のコマンドを実行してください。
GCCのプラグイン開発用インクルードパスを取得して共有ライブラリとしてコンパイルする
g++ -shared -fPIC -O2 \
-I$(g++ -print-file-name=plugin)/include \
my_security_plugin.c \
-o my_security_plugin.dll
> コマンド解説:
> `g++ -print-file-name=plugin` は、お使いのGCCが持っているプラグインヘッダへのパスを動的に取得する魔法のコマンドです。これにより、バージョン差異によるパスの悩みを完全に解消できます。
実行に成功すると、同ディレクトリに `my_security_plugin.dll` が生成されます。
—
テスト用プログラムの作成
次に、このプラグインが実際に動作するかを試すためのターゲットコードを用意します。
`test.c` というファイルを作成してください。
include
include
void normal_function() {
char buf[10];
// あえて危険なstrcpyを使用する
strcpy(buf, “hello”);
}
int main() {
printf(“Hello, GCC Plugin World!\n”);
normal_function();
return 0;
}
—
プラグインを適用したコンパイルの実行
いよいよ、作成した自作プラグインをGCCに読み込ませて `test.c` をコンパイルします！
-fpluginオプションで自作のDLLを指定してコンパイルを実行
gcc -fplugin=./my_security_plugin.dll test.c -o test.exe
実行結果（コンソールログ）:
>>> 成功: 自作セキュリティプラグイン ‘my_security_check’ がロードされました。
test.c: In function ‘normal_function’:
test.c:7:5: warning: 【セキュリティ警告】危険な関数 ‘strcpy’ が検出されました！代わりに ‘strncpy’ を使ってください。 [-Wplugin]
7 | strcpy(buf, “hello”);
| ^~~~~~
見事な警告が出ました！
通常のGCCの警告設定には存在しない、私たちがたった今定義したばかりの日本語の警告メッセージが、ソースコードの正確な行数（`test.c:7:5`）と共に表示されています。
—
5. 現場でこの技術がもたらす計り知れないメリット
「コンパイラのプラグインなんて、研究室のオモチャでしょ？」と思われるかもしれませんが、実務の現場において、このアプローチは以下のような計り知れない価値をもたらします。
1. レガシーコードの強制モダナイゼーション
大規模なC/C++プロジェクトで、「古い危険なAPI（例: `sprintf`, `strcpy`, 生の `malloc` など）を新しい安全なラッパー関数に段階的に置き換えたい」という要件があったとします。ドキュメントで禁止令を出すだけでは必ず破られますが、コンパイル時に問答無用でエラーや警告にするプラグインを導入すれば、ルール遵守を100%自動化できます。
2. ドメイン特化型最適化（DSL的なコード変換）
今回は「警告の出力」を行いましたが、GCCプラグインのGIMPLEツリー書き換えAPIを使えば、特定の演算を高速な社内製ライブラリ関数への呼び出しに自動置換（トランスレート）することも可能です。開発者は特別なツールを通す必要がなく、ただ `make` や `cmake` を叩くだけで、勝手にコードが最適化されます。
3. CI/CDパイプラインとの完全統合
MSYS2/MinGW-w64環境のCI（GitHub Actions等）でも、この `.dll`（Linux環境であれば `.so`）を持ち込むだけで、追加の複雑な静的解析ツールをインストールすることなく、高速に独自の静子解析を走らせることができます。
—
おわりに
今回は、MinGW-w64 / MSYS2 環境における GCCプラグイン開発の扉を叩き、独自の警告をコンパイルプロセスにねじ込むところまでを解説しました。
コンパイラは、単なる「ソースコードを機械語に翻訳するブラックボックス」ではありません。適切なAPIを使えば、あなた専属の強力なコード番人へと変貌させることができます。
これをマスターすれば、毎日のコーディングやコードレビューのストレスが劇的に軽くなり、チーム全体のコード品質を次の次元へと引き上げることができますよ。ぜひ、ご自身のプロジェクトのルールに合わせて、この魔法をカスタマイズしてみてください。あなたの開発ライフがより創造的で楽しいものになることを応援しています！