MinGW-w64のGCCプラグイン開発入門：独自の警告やコード変換を自作する魔法
テックリードの皆さん、日々のC/C++開発で「既存の静的解析ツールでは検出できない、我が社固有のアーキテクチャ違反やアンチパターンをビルド時に弾きたい」「特定の危険な関数呼び出しを、別の安全なラッパー関数へコンパイル時に強制置換したい」と思ったことはないでしょうか。
LinterやClang-Tidyを導入するのも一つの手ですが、プロジェクト固有の複雑な意味論（Semantics）を解釈させようとすると、設定ファイルの記述量が増大し、メンテナンス地獄に陥りがちです。
ここで取り札となるのが、「GCCプラグイン（GCC Plugins）」です。
GCCの内部構造であるGIMPLE/SSA表現に直接介入し、コンパイラの最適化パスの合間に独自の処理（静的解析やコード変換）をねじ込むこの手法は、コンパイラを完全に手なずけるための「究極の魔法」です。
今回は、Windows（MinGW-w64 / MSYS2）環境を舞台に、GCCプラグインを自作し、コンパイルプロセスをハックする深淵なる世界へあなたを案内します。
—
1. なぜ「MinGW-w64上のGCCプラグイン」なのか：アーキテクトの視点
多くの開発者は、GCCを「ソースコードをバイナリに変換するブラックボックス」として扱っています。しかし、GCCはバージョン4.5以降、プラグイン機構を正式にサポートしており、コンパイルの各フェーズ（構文木構築、GIMPLE最適化、RTL生成など）に任意の共有ライブラリ（`.dll` / `.so`）をフックさせることができます。
Linux環境であれば比較的容易なこのプラグイン開発も、MinGW-w64 (Windows) 環境になると、PE/COFF形式特有のシンボルエクスポート問題や、クロスコンパイルに起因するヘッダの不整合など、幾多の罠が待ち受けています。しかし、この環境を制覇すれば、Windowsネイティブのビルドパイプラインに完全に統合された、極めて高速かつ強力な独自コード検証・変換エンジンを手に入れることができます。
開発スピードを劇的に高めるMSYS2の隠れたショートカット & 設定
MinGW-w64環境を構築するMSYS2において、日々の開発・デバッグ効率を極限まで高めるための実践的な設定とショートカットを共有します。
- シェル環境の最適化 (`~/.bashrc` / `~/.inputrc`)
GCCプラグインの開発では、コンパイル・ロード・テストのサイクルを高速に回す必要があります。履歴検索のファジーマッチ化は必須です。
# ~/.inputrc の設定：Ctrl+P / Ctrl+N でプレフィックス一致検索を有効化
“\e[A”: history-search-backward
“\e[B”: history-search-forward
- 絶対入れるべきMSYS2パッケージ群
プラグイン開発には、GCC本体だけでなく、内部表現を解釈するための開発ヘッダやデバッグツールが必要です。以下のコマンド一発で環境を同期させてください。
pacman -S –needed base-devel mingw-w64-ucrt-x86_64-toolchain mingw-w64-ucrt-x86_64-gdb mingw-w64-ucrt-x86_64-pkg-config
—
2. GCCプラグインの内部構造と動作原理
GCCプラグインは、コンパイラが起動した際に動的ロード（`dlopen` / `LoadLibrary`）されます。プラグインのエントリポイントである `plugin_init` 関数が呼ばれ、そこでGCCの内部イベント（パスの登録、イベントリスナーの設定など）に自作のコールバック関数を登録します。
[源コード (.c)]
│
▼
[GCC フロントエンド] ──> [GIMPLE (中間表現)]
│
▼
【★ 自作プラグインのパス挿入】
(静的解析 / AST・GIMPLE書換え)
│
▼
[RTL (Register Transfer Language)]
│
▼
[バイナリ (.exe / .dll)]
今回作成するプラグインでは、GIMPLEパス（高水準中間表現の最適化パス）の直前に割って入り、ソースコード内の特定の関数呼び出し（例: `strcpy` や禁止された独自関数）を検出して警告を出し、さらに安全な関数へ強制置換するロジックを実装します。
—
3. 実践：独自の警告とコード変換を行うプラグインの作成
それでは、実際にコードを書いていきます。以下のCソースコード（`my_plugin.c`）は、GCCのプラグインAPIを叩き、関数呼び出しをインターセプトする最小にして最強のサンプルです。
プラグイン本体コード：`my_plugin.c`
include
include “gcc-plugin.h”
include “plugin-version.h”
include “tree.h”
include “basic-block.h”
include “gimple.h”
include “gimple-iterator.h”
include “tree-pass.h”
include “context.h”
// プラグインのライセンス宣言（GCCの要件）
int plugin_is_GPL_compatible;
// 1. 独自パスの定義構造体
const pass_data my_custom_pass_data = {
GIMPLE_PASS, // GIMPLE中間表現に対するパス
“my_security_check”, // パス名（-fopt-infoなどで表示される）
OPTGROUP_NONE, // 最適化グループ
TV_NONE, // タイムバ変数
0, // 実行条件フラグ
0, // 停止条件フラグ
0, // 処理対象のプロパティ追加
0, // 処理対象のプロパティ削除
};
// パスの実体を定義
struct my_custom_pass : public gimple_opt_pass {
my_custom_pass(gcc::context ctx)
: gimple_opt_pass(my_custom_pass_data, ctx) {}
// 各関数（Function）の処理単位で呼ばれる実行関数
virtual unsigned int execute(function fun) {
gimple_stmt_iterator gsi;
basic_block bb;
// 基本ブロック（Basic Block）を走査
FOR_EACH_BB_FN(bb, fun) {
// 基本ブロック内の文（Statement）を走査
for (gsi = gsi_start_bb(bb); !gsi_end_p(gsi); gsi_next(&gsi)) {
gimple stmt = gsi_stmt(gsi);
// 文が「関数呼び出し（GIMPLE_CALL）」か判定
if (is_gimple_call(stmt)) {
tree fndecl = gimple_call_fndecl(stmt);
if (fndecl) {
const char func_name = IDENTIFIER_POINTER(DECL_NAME(fndecl));
// 例：危険な関数 “dangerous_func” を検出
if (strcmp(func_name, “dangerous_func”) == 0) {
// 警告を強制出力（コンパイルエラーにも昇格可能）
warning_at(gimple_location(stmt), 0,
“【セキュリティ警告】廃止された dangerous_func が検出されました！”);
// 応用：ここで gimple_call_set_fndecl を使って
// 安全な関数 “safe_func” への書き換え（コード変換）も可能！
}
}
}
}
}
return 0;
}
};
// 2. パスをGCCのパスツリーに登録するコールバック関数
static gimple_opt_pass my_pass_instance = NULL;
static void register_my_pass(void event_data, void user_data) {
// パスの挿入位置を決める構造体
opt_pass pass_to_insert = my_pass_instance;
struct register_pass_info pass_info;
pass_info.pass = pass_to_insert;
pass_info.reference_pass_name = “cfg”; // Control Flow Graph構築の直後に挿入
pass_info.ref_pass_instance_number = 1;
pass_info.pos_op = PASS_POS_INSERT_AFTER;
// GCC内部のパスマネージャへ登録
register_callback(“my_plugin”, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info);
}
// 3. プラグインのエントリポイント
int plugin_init(struct plugin_name_args plugin_info,
struct plugin_version version) {
// バージョンの一致確認（GCCのバージョンとプラグインの互換性チェック）
if (!plugin_default_version_check(version, &gcc_version)) {
fprintf(stderr, “エラー: GCCのバージョンが一致しません。\n”);
return 1;
}
// パスのインスタンス生成
my_pass_instance = new my_custom_pass(g);
// パス登録イベントのハンドラを登録
register_callback(plugin_info->base_name, PLUGIN_INFO, NULL, &plugin_info);
register_callback(plugin_info->base_name, PLUGIN_START_UNIT, register_my_pass, NULL);
return 0;
}
—
4. MinGW-w64環境でのビルドとコンパイルパイプライン統合
GCCプラグインをビルドするには、GCC本体が内部で使用しているプラグイン用ヘッダ（`-I`オプションで指定）が必要です。MinGW-w64 (UCRT64環境) では、これらは標準で適切なパスに配置されています。
ビルド用シェルスクリプト：`build_plugin.sh`
以下のスクリプトを用いて、プラグインのソースコードを共有ライブラリ（`.dll`）へコンパイルします。
!/bin/bash
set -e
ターゲットのプラグイン名
PLUGIN_NAME=”my_plugin”
MinGW-w64のGCCプラグイン開発用インクルードディレクトリを取得
GCC_PLUGIN_DIR=$(gcc -print-file-name=plugin)
echo “==> GCCプラグインヘッダパス: $GCC_PLUGIN_DIR”
共有ライブラリ（.dll）としてコンパイル
-shared: 共有ライブラリを作成
-fPIC: 位置独立コード（MinGWでは暗黙的に処理されますが明示）
g++ -shared -o ${PLUGIN_NAME}.dll ${PLUGIN_NAME}.c \
-I”${GCC_PLUGIN_DIR}/include” \
-I”${GCC_PLUGIN_DIR}/include/cp” \
-std=c++17 \
-O2 \
-Wno-literal-suffix
echo “==> プラグインのビルドが完了しました: ${PLUGIN_NAME}.dll”
—
5. 動作検証：自作プラグインによる静検知のテスト
実際にプラグインが機能するかどうかをテストするためのターゲットコード（`test.c`）を用意します。
テスト対象コード：`test.c`
include
// 検出対象のダミー関数
void dangerous_func(void) {
printf(“危険な処理を実行中…\n”);
}
void safe_func(void) {
printf(“安全な処理を実行中…\n”);
}
int main(void) {
printf(“テスト開始\n”);
// ここがプラグインによって検出されるべき箇所
dangerous_func();
safe_func();
return 0;
}
コンパイルと実行ログ
作成したプラグイン（`my_plugin.dll`）を `-fplugin` オプションでGCCに読み込ませてコンパイルを実行します。
$ ./build_plugin.sh
==> GCCプラグインヘッダパス: /ucrt64/lib/gcc/x86_64-w64-mingw32/13.2.0/plugin
==> プラグインのビルドが完了しました: my_plugin.dll
$ gcc -fplugin=./my_plugin.dll test.c -o test.exe
test.c: In function ‘main’:
test.c:16:5: warning: 【セキュリティ警告】廃止された dangerous_func が検出されました！ [-Wplugin]
16 | dangerous_func();
| ^~~~~~~~~~~~~~~~
$ ./test.exe
テスト開始
危険な処理を実行中…
安全な処理を実行中…
成功です！ ソースコードを一切変更することなく、コンパイル時に独自作成した警告文が正確に発火していることが確認できます。さらにプラグイン側のコードを拡張すれば、警告を出すだけでなく、`gimple_call_set_fndecl` を用いてAST/GIMPLEレベルで `dangerous_func` の呼び出しを自動的に `safe_func` に書き換える（コード変換）ことも可能です。
—
6. チーム開発で役立つ設定の共有化ルールとベストプラクティス
このようなコンパイラ拡張をチーム開発に導入する場合、個人のローカル環境だけにプラグインを導入するのでは意味がありません。全メンバーのビルド環境で一貫して動作させるためのベストプラクティスを提示します。
1. タスクランナー（Makefile / CMake）によるプラグインの自動ビルド & 適用
プロジェクトのルートに配置する `CMakeLists.txt` において、特定のフラグが有効な場合に自作プラグインをロードする設定を埋め込みます。
cmake_minimum_required(VERSION 3.20)
project(SecureProject C)
set(CMAKE_C_STANDARD 11)
自作プラグインのパスを指定
set(MY_GCC_PLUGIN “${CMAKE_SOURCE_DIR}/cmake/plugins/my_plugin.dll”)
コンパイラがGCCであり、かつプラグインが存在する場合に自動適用
if(CMAKE_C_COMPILER_ID STREQUAL “GNU” AND EXISTS “${MY_GCC_PLUGIN}”)
message(STATUS “カスタムGCCセキュリティプラグインを有効化します。”)
add_compile_options(“-fplugin=${MY_GCC_PLUGIN}”)
endif()
add_executable(SecureProject main.c test.c)
2. 設定ファイルのベストプラクティス（CI/CD連携用 `ci-config.yaml`）
GitLab CIやGitHub ActionsなどのCI/CDパイプライン上で、プラグインを含めたビルドを再現するための設定例です。MSYS2環境をコンテナやランナー上で正確に構築し、静的解析パスを強制します。
.github/workflows/gcc-plugin-build.yml
name: GCC Plugin Static Analysis
on:
push:
branches: [ “main”, “develop” ]
pull_request:
branches: [ “main” ]
jobs:
build-with-plugin:
runs-on: windows-latest
defaults:
run:
shell: msys2 {0} # MSYS2のUCRT64シェルを明示的に指定
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Setup MSYS2 Environment
uses: msys2/setup-msys2@v2
with:
msystem: UCRT64
update: true
install: >-
base-devel
mingw-w64-ucrt-x86_64-toolchain
mingw-w64-ucrt-x86_64-cmake
- name: Build Custom GCC Plugin
run: |
cd cmake/plugins
./build_plugin.sh
- name: Configure and Build Project with Plugin
run: |
mkdir build && cd build
cmake -G “MinGW Makefiles” ..
cmake –build .
—
最後に：コンパイラを飼い慣らす者へ
GCCプラグイン開発は、一見すると敷居が高く、コンパイラの内部構造（GIMPLEやTree構造）という難解なドメイン知識を要求されます。しかし、一度この扉を開ければ、既存のツールや静的解析器の制約から完全に解放され、「自分たちのコードベースのルールを、コンパイラそのものに強制させる」という圧倒的なコントロール力を手に入れることができます。
レガシーなC/C++の大規模コードベースをモダンで安全な要塞へと変貌させるために、ぜひこの「魔法」をあなたの現場のビルドパイプラインに組み込んでみてください。チームの生産性とコード品質は、次の次元へと飛躍するはずです。