ベアメタル開発の最終防衛線：GDB Remote Serial Protocol (RSP) 完全自作による、特殊マイコン・自作OSデバッグ環境の構築術
数多のコンテナ、抽象化されたクラウドCI/CD、リッチなIDEによるデバッグ環境に慣れ親しんだ現代のエンジニアにとって、「GDBが標準サポートしない独自アーキテクチャのマイコン」や「前人未到の自作OS」のデバッグは、まさに暗黒の領域である。
既存の `OpenOCD` や `gdbserver` が手当てできない環境に直面したとき、多くの開発者はシリアル通信による `printf` デバッグという、先史時代の手法へと退化していく。しかし、プロフェッショナルな組み込みアーキテクトにとって、それは敗北を意味する。
GDBの内部で稼働する通信プロトコル RSP (Remote Serial Protocol) の仕様を完全に把握し、ターゲット側の数キロバイトのメモリ空間に最小限のスタブを実装すれば、どんな異形ハードウェアであっても、最高峰のソースレベル・デバッグ環境へと昇華させることが可能だ。
本稿では、RSPのパケット構造の深淵から、シリアル/JTAGを介した双方向通信、さらにはDockerコンテナを用いたCI/CDパイプラインへの統合に至るまで、低レイヤの髄を極めたカスタム・デバッグ環境の構築術を詳解する。
—
1. 内部アーキテクチャの核心：GDB RSP（Remote Serial Protocol）の正体
GDBとターゲット側のデバッグ・エージェント（スタブ）の間では、TCPソケットやUART（シリアル通信）を介して、純粋なテキストベースのパケットが飛び交っている。これが RSP (Remote Serial Protocol) である。
パケット構造の解剖学
RSPの基本フォーマットは極めてプリミティブかつ堅牢に設計されている。
$[データペイロード}#<チェックサム（2桁の16進数）>
ターゲット側で異常が発生した場合や、GDB側からの割り込み（Ctrl+C相当）を受け取ると、以下の形式で非同期の「停止応答（Stop Reply Packet）」が返される。
$T<シグナル番号>thread:<スレッドID>;<レジスタ名>:<値>;…#<チェックサム>
なぜ自作スタブが必要なのか？
市販のJTAGプローブ（SEGGER J-LinkやST-Linkなど）は汎用性が高いが、以下のような極限環境では無力化する。
1. 非標準のコア・アーキテクチャ（自作FPGAソフトコア、独自ISAのASIC）
2. 極小のRAM制約（RAMが数KBしかなく、市販のデバッグファームウェアが常駐できない）
3. 物理インターフェースの制約（JTAGピンが引き出せず、UARTの1本だけでデバッグを通したい）
この壁を突破するには、マイコンの例外ベクタ（Exception Vector）を乗っ取り、CPUの全レジスタ退避処理とRSPパーサをごく少量のC/アセンブリで書き下ろす必要がある。
—
2. 最小限のベアメタルRSPスタブの実装設計
ターゲット側（マイコン）に実装すべき「RSPスタブ」のミニマムな構造を定義する。
ターゲットがトラップ（ブレークポイント命令 `ebreak` や不正メモリアクセスなど）にヒットした際、CPUは例外ハンドラにジャンプし、以下のC言語関数（またはアセンブリ・ラッパー）に制御を渡す。
include
// レジスタコンテキストの定義（CPUアーキテクチャ依存）
typedef struct {
uint32_t r[16]; // 一般レジスタ
uint32_t pc; // プログラムカウンタ
uint32_t sp; // スタックポインタ
} __attribute__((packed)) target_regs_t;
// シリアルポート経由の送受信プリミティブ（ハードウェア依存）
extern char uart_getchar(void);
extern void uart_putchar(char c);
// 8ビットチェックサムの計算（RSPの必須要件）
static uint8_t calc_checksum(const char data, int len) {
uint8_t sum = 0;
for (int i = 0; i < len; i++) {
sum += data[i];
}
return sum;
}
// GDBからのパケットを受信し、バッファに格納する
int rsp_get_packet(char buf, int max_len) {
char c;
while (1) {
c = uart_getchar();
if (c == '$') break; // パケット開始文字を待つ
if (c == 0x03) return -1; // Ctrl+C 割り込み
}
int idx = 0;
while (idx < max_len - 1) {
c = uart_getchar();
if (c == '#') {
buf[idx] = '\0';
// 続く2文字のチェックサムを読み飛ばす
uart_getchar();
uart_getchar();
uart_putchar('+'); // 正常受信の確認応答 (ACK)
return idx;
}
buf[idx++] = c;
}
return -2; // バッファオーバーフロー
}
// GDBへ応答パケットを送信する
void rsp_send_packet(const char payload) {
char checksum_str[3];
int len = 0;
while (payload[len] != '\0') len++;
uint8_t cs = calc_checksum(payload, len);
// 16進数チェックサムを2桁の文字列へ変換する
const char hex[] = "0123456789abcdef";
checksum_str[0] = hex[(cs >> 4) & 0x0F];
checksum_str[1] = hex[cs & 0x0F];
checksum_str[2] = ‘\0’;
do {
uart_putchar(‘$’);
for (int i = 0; i < len; i++) uart_putchar(payload[i]);
uart_putchar('#');
uart_putchar(checksum_str[0]);
uart_putchar(checksum_str[1]);
} while (uart_getchar() != '+'); // GDBから '+' (ACK) が返るまで再送
}
// デバッグ例外ハンドラのエントリーポイント
void gdb_debug_handler(target_regs_t regs) {
char rx_buf[256];
char tx_buf[256];
// ターゲットが停止したことをGDBへ通知（シグナル5 = SIGTRAP）
rsp_send_packet("S05");
while (1) {
int len = rsp_get_packet(rx_buf, sizeof(rx_buf));
if (len < 0) continue;
// パケット種別ごとのディスパッチ
switch (rx_buf[0]) {
case 'g': // レジスタ一括読み出し要求
// 実装例: regs構造体の内容を16進数文字列にエンコードして返す
rsp_send_packet("00000000...00000000");
break;
case 'c': // 実行再会 (Continue)
// 例外ハンドラを抜けて処理を続行
return;
case 'q': // クエリコマンド (supported featuresなど)
rsp_send_packet("PacketSize=1024");
break;
default:
// 未実装のコマンドには空文字列を返し、プロトコルの破綻を防ぐ
rsp_send_packet("");
break;
}
}
}
---
3. ホスト側：GDBからカスタムRSPターゲットへの接続と自動化
マイコン側でシリアル（あるいは仮想シリアル）経由のRSPが動作したら、ホスト側のGDBから接続を行う。ここで毎回手動でコマンドを叩くようではDevOpsの思想に反する。完全自動化のためのGDB初期化スクリプト（`.gdbinit`）を設計する。
高度な `.gdbinit` 設定ファイル
以下の設定により、接続断時の自動リトライ、シンボルファイルの自動ロード、ブレークポイントの永続化を自動化する。
ターゲットアーキテクチャの明示的指定（例: 32ビットRISC-V）
set architecture riscv:rv32
リモート接続時のタイムアウト設定（ミリ秒単位。不安定なUART回線対策）
set remotetimeout 10
バイナリのロードとデバッグ情報の紐付け
file build/firmware.elf
ターゲットのシリアルデバイス（またはsocat等でブリッジしたTCPポート）への接続
例: /dev/ttyUSB0 をボーレート115200でオープン
target remote /dev/ttyUSB0
接続成功時に自動で main 関数にブレークポイントを仕掛ける
break main
ターゲットをリセットして実行開始（必要に応じて）
monitor reset
—
4. Dockerコンテナ環境による「完全再現性」のデバッグ基盤
ハードウェアに依存する組み込み開発において最大の課題は、「開発者のローカルPCでしか動かない」という環境依存のバグである。これを排除するため、シリアルポート（`/dev/tty`）をコンテナ内にパススルーし、GDBおよびクロスコンパイラをコンテナ内に完全にカプセル化する。
Dockerfile（開発・CI共通のベース環境）
FROM ubuntu:22.04
非対話モードの設定と必須ツールのインストール
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y \
build-essential \
gdb-multiarch \
git \
picocom \
socat \
python3 \
&& rm -rf /var/lib/apt/lists/
ワークディレクトリの設定
WORKDIR /workspace
エントリポイントとしてシェルを指定
CMD [“/bin/bash”]
docker-compose.yml（ホストの物理シリアルをコンテナへ安全にブリッジ）
ホストマシンのシリアルデバイスをコンテナに直結し、コンテナ内からシリアル通信を伴うデバッグを可能にする。
version: ‘3.8’
services:
embedded-debugger:
build: .
image: embedded-debug-env:latest
container_name: rsv_debug_container
# 特権モード、または特定のデバイスへのアクセス権を付与
privileged: true
devices:
- “/dev/ttyUSB0:/dev/ttyUSB0”
volumes:
- .:/workspace
# 接続を維持するためのインタラクティブ設定
stdin_open: true
tty: true
command: /bin/bash
この構成により、ホストOSの差異（macOS, Ubuntu, Windows+WSL2）に一切依存することなく、同一の `gdb-multiarch` バイナリとスクリプトでターゲットを叩くことが保証される。
—
5. CI/CDパイプラインとの高度な統合：ハードウェア・イン・ザ・ループ (HIL) テストの自動化
「コードをプッシュしたら、実機上でテストファームウェアが走り、アサート違反やハードフォールトが発生していないかをGDB経由で自動検証する」――これこそが、最先端の組み込みDevOps体制である。
GitHub Actions または GitLab CI において、シリアル接続された実機（あるいはQEMU等のカスタムシミュレータ）を制御し、非対話モード（Batch Mode）でGDBを走らせるCIスクリプトを構築する。
自動テスト用 Python スクリプト（`ci_gdb_runner.py`）
GDBのPython API (`gdb` モジュール) を利用し、GDBを内部から操作してテスト結果を自動回収する。
import subprocess
import sys
import time
def run_automated_debug_session():
# GDBをバッチモードかつマイコン用クロスバイナリで起動
gdb_command = [
“gdb-multiarch”,
“-q”,
“-x”, “.gdbinit_ci”
]
print(“[INFO] Starting automated GDB session against target…”)
process = subprocess.Popen(
gdb_command,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
text=True
)
# ログを監視し、テスト成功・失敗の判定文字列をキャッチする
test_passed = False
timeout_counter = 0
while process.poll() is None:
output = process.stdout.readline()
if output:
print(f”[GDB] {output.strip()}”)
if “TEST_SUCCESS” in output:
test_passed = True
break
if “TEST_FAIL” in output or “SIGTRAP” in output:
test_passed = False
break
time.sleep(0.1)
timeout_counter += 1
if timeout_counter > 300: # 30秒タイムアウト
print(“[ERROR] GDB session timed out.”)
process.terminate()
sys.exit(1)
process.terminate()
if test_passed:
print(“[SUCCESS] Hardware-in-the-loop test passed successfully!”)
sys.exit(0)
else:
print(“[FAILURE] Hardware-in-the-loop test failed.”)
sys.exit(1)
if __name__ == “__main__”:
run_automated_debug_session()
非対話CI用 `.gdbinit_ci`
file build/firmware_test.elf
target remote /dev/ttyUSB0
全てのブレークポイントで停止せず、バックトレースを出力して続行させるなどの制御が可能
break test_assert_failed
commands
echo \n[CI_LOG] TEST_FAIL: Assertion triggered on hardware!\n
backtrace
quit 1
end
break test_finished
commands
echo \n[CI_LOG] TEST_SUCCESS: All assertions passed!\n
quit 0
end
実行開始
continue
この仕組みをCIパイプラインに組み込むことで、手動での実機デバッグ工数をゼロにし、ハードウェア変更に伴うリグレッションを完全に排除することが可能となる。
—
結び：低レイヤを掌握する者だけが手にする絶対的な優位性
市販のツールチェインが提供する「便利で重厚なエコシステム」は、平時の開発スピードを加速させるが、ひとたび未知のバグやアーキテクチャの限界に突き当たったとき、それは開発者を縛る足枷へと変貌する。
今回解説した GDB RSPの自作、コンテナによる完全な環境のコード化、そして CIパイプラインへのHIL統合 は、単なる技術的ハックではない。それは、ハードウェアの挙動を底层のパケットレベルから完全に掌握し、開発ライフサイクル全体の主導権を取り戻すための「エンジニアリングの極み」である。
ツールに使われるな。ツールを創り、支配せよ。