🛠️ Gdb CLI
AIプログラムの不具合を特定し、
📺 まず動画で見る(YouTube)
▶ 【衝撃】最強のAIエージェント「Claude Code」の最新機能・使い方・プログラミングをAIで効率化する超実践術を解説! ↗
※ jpskill.com 編集部が参考用に選んだ動画です。動画の内容と Skill の挙動は厳密には一致しないことがあります。
📜 元の英語説明(参考)
GDB debugging assistant for AI agents - analyze core dumps, debug live processes, investigate crashes and deadlocks with source code correlation
🇯🇵 日本人クリエイター向け解説
AIプログラムの不具合を特定し、
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o gdb-cli.zip https://jpskill.com/download/2912.zip && unzip -o gdb-cli.zip && rm gdb-cli.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/2912.zip -OutFile "$d\gdb-cli.zip"; Expand-Archive "$d\gdb-cli.zip" -DestinationPath $d -Force; ri "$d\gdb-cli.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
gdb-cli.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
gdb-cliフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
💬 こう話しかけるだけ — サンプルプロンプト
- › Gdb CLI を使って、最小構成のサンプルコードを示して
- › Gdb CLI の主な使い方と注意点を教えて
- › Gdb CLI を既存プロジェクトに組み込む方法を教えて
これをClaude Code に貼るだけで、このSkillが自動発動します。
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
GDB デバッグアシスタント
概要
AI エージェント向けに設計された GDB デバッグスキルです。ソースコード分析と gdb-cli を使用したランタイム状態の検査を組み合わせることで、C/C++ プログラムに対するインテリジェントなデバッグ支援を提供します。
このスキルを使用する場面
- コアダンプまたはクラッシュダンプの分析
- GDB アタッチによる実行中のプロセスのデバッグ
- クラッシュ、デッドロック、またはメモリの問題の調査
- ソースコードのコンテキストを伴うインテリジェントなデバッグ支援の取得
- マルチスレッドアプリケーションのデバッグ
このスキルを使用しない場面
- タスクが C/C++ デバッグと無関係な場合
- ユーザーがデバッグなしで汎用的な支援を必要とする場合
- GDB が利用できない場合(Python サポート付きの GDB 9.0 以降が必要です)
前提条件
# gdb-cli をインストールします
pip install gdb-cli
# または GitHub からインストールします
pip install git+https://github.com/Cerdore/gdb-cli.git
# GDB に Python サポートがあることを確認します
gdb -nx -q -batch -ex "python print('OK')"
要件:
- Python 3.6.8 以降
- Python サポートが有効な GDB 9.0 以降
- Linux OS
動作原理
ステップ 1: デバッグセッションの初期化
コアダンプ分析の場合:
gdb-cli load --binary <binary_path> --core <core_path> [--gdb-path <gdb_path>]
ライブプロセスデバッグの場合:
gdb-cli attach --pid <pid> [--binary <binary_path>]
出力: "session_id": "a1b2c3" のような session_id です。後続のコマンドのためにこれを保存してください。
ステップ 2: 初期情報の収集
SESSION="<session_id>"
# すべてのスレッドをリスト表示します
gdb-cli threads -s $SESSION
# バックトレースを取得します(ローカル変数付き)
gdb-cli bt -s $SESSION --full
# レジスタを取得します
gdb-cli registers -s $SESSION
ステップ 3: ソースコードの関連付け(重要)
バックトレースの各フレームについて:
- フレーム情報を抽出します:
{file}:{line} in {function} - ソースコンテキストを読み取ります: クラッシュ箇所の前後 ±20 行を取得します
- ローカル変数を取得します:
gdb-cli locals-cmd -s $SESSION --frame <N> - 分析します: コードロジックと変数の値を関連付けます
関連付けの例:
Frame #0: process_data() at src/worker.c:87
Source code shows:
85: Node* node = get_node(id);
86: if (node == NULL) return;
87: node->data = value; <- Crash here
Variables show:
node = 0x0 (NULL)
Analysis: The NULL check on line 86 didn't catch the issue.
ステップ 4: 詳細調査
# 変数を検査します
gdb-cli eval-cmd -s $SESSION "variable_name"
gdb-cli eval-cmd -s $SESSION "ptr->field"
gdb-cli ptype -s $SESSION "struct_name"
# メモリ検査
gdb-cli memory -s $SESSION "0x7fffffffe000" --size 64
# 逆アセンブル
gdb-cli disasm -s $SESSION --count 20
# すべてのスレッドを確認します(デッドロック分析用)
gdb-cli thread-apply -s $SESSION bt --all
# 共有ライブラリを表示します
gdb-cli sharedlibs -s $SESSION
ステップ 5: セッション管理
# アクティブなセッションをリスト表示します
gdb-cli sessions
# セッションステータスを確認します
gdb-cli status -s $SESSION
# セッションを停止します(クリーンアップ)
gdb-cli stop -s $SESSION
一般的なデバッグパターン
パターン: ヌルポインタの逆参照
兆候:
- メモリアクセス命令でのクラッシュ
- ポインタ変数が 0x0
調査:
gdb-cli registers -s $SESSION # RIP を確認します
gdb-cli eval-cmd -s $SESSION "ptr" # ポインタ値を確認します
パターン: デッドロック
兆候:
- 複数のスレッドがロック関数でスタックしている
- バックトレースに
pthread_mutex_lockがある
調査:
gdb-cli thread-apply -s $SESSION bt --all
# 循環待機パターンを探します
パターン: メモリ破損
兆候:
- malloc/free でのクラッシュ
- 変数にゴミ値がある
調査:
gdb-cli memory -s $SESSION "&variable" --size 128
gdb-cli registers -s $SESSION
例
例 1: コアダンプ分析
# コアダンプをロードします
gdb-cli load --binary ./myapp --core /tmp/core.1234
# クラッシュ箇所を取得します
gdb-cli bt -s a1b2c3 --full
# クラッシュフレームを検査します
gdb-cli locals-cmd -s a1b2c3 --frame 0
例 2: ライブプロセスデバッグ
# スタックしたサーバーにアタッチします
gdb-cli attach --pid 12345
# すべてのスレッドを確認します
gdb-cli threads -s b2c3d4
# すべてのバックトレースを取得します
gdb-cli thread-apply -s b2c3d4 bt --all
ベストプラクティス
- 変数の値から結論を導き出す前に、必ずソースコードを読んでください
- スレッド数が多い場合やバックトレースが深い場合は、ページネーションのために
--rangeを使用してください - 値を検査する前に、
ptypeを使用して複雑なデータ構造を理解してください - マルチスレッドの問題については、すべてのスレッドを確認してください
- 型をソースコードの定義と相互参照してください
セキュリティと安全に関する注意
- このスキルは、プロセスとコアダンプへの GDB アクセスを必要とします
- プロセスへのアタッチには、適切な権限(sudo、ptrace_scope)が必要な場合があります
- コアダンプには機密データが含まれている可能性があるため、慎重に取り扱ってください
- 分析する権限のあるプロセスのみをデバッグしてください
関連スキル
@systematic-debugging- 一般的なデバッグ手法@test-driven-development- 実装前にテストを作成する
リンク
- リポジトリ: https://github.com/Cerdore/gdb-cli
- PyPI: https://pypi.org/project/gdb-cli/
- ドキュメント: https://github.com/Cerdore/gdb-cli#readme
制限事項
- このスキルは、タスクが上記の範囲と明確に一致する場合にのみ使用してください。
- 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全境界、または成功基準が不足している場合は、停止して説明を求めてください。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
GDB Debugging Assistant
Overview
A GDB debugging skill designed for AI agents. Combines source code analysis with runtime state inspection using gdb-cli to provide intelligent debugging assistance for C/C++ programs.
When to Use This Skill
- Analyze core dumps or crash dumps
- Debug running processes with GDB attach
- Investigate crashes, deadlocks, or memory issues
- Get intelligent debugging assistance with source code context
- Debug multi-threaded applications
Do Not Use This Skill When
- The task is unrelated to C/C++ debugging
- The user needs general-purpose assistance without debugging
- No GDB is available (GDB 9.0+ with Python support required)
Prerequisites
# Install gdb-cli
pip install gdb-cli
# Or from GitHub
pip install git+https://github.com/Cerdore/gdb-cli.git
# Verify GDB has Python support
gdb -nx -q -batch -ex "python print('OK')"
Requirements:
- Python 3.6.8+
- GDB 9.0+ with Python support enabled
- Linux OS
How It Works
Step 1: Initialize Debug Session
For core dump analysis:
gdb-cli load --binary <binary_path> --core <core_path> [--gdb-path <gdb_path>]
For live process debugging:
gdb-cli attach --pid <pid> [--binary <binary_path>]
Output: A session_id like "session_id": "a1b2c3". Store this for subsequent commands.
Step 2: Gather Initial Information
SESSION="<session_id>"
# List all threads
gdb-cli threads -s $SESSION
# Get backtrace (with local variables)
gdb-cli bt -s $SESSION --full
# Get registers
gdb-cli registers -s $SESSION
Step 3: Correlate Source Code (CRITICAL)
For each frame in the backtrace:
- Extract frame info:
{file}:{line} in {function} - Read source context: Get ±20 lines around the crash point
- Get local variables:
gdb-cli locals-cmd -s $SESSION --frame <N> - Analyze: Correlate code logic with variable values
Example correlation:
Frame #0: process_data() at src/worker.c:87
Source code shows:
85: Node* node = get_node(id);
86: if (node == NULL) return;
87: node->data = value; <- Crash here
Variables show:
node = 0x0 (NULL)
Analysis: The NULL check on line 86 didn't catch the issue.
Step 4: Deep Investigation
# Examine variables
gdb-cli eval-cmd -s $SESSION "variable_name"
gdb-cli eval-cmd -s $SESSION "ptr->field"
gdb-cli ptype -s $SESSION "struct_name"
# Memory inspection
gdb-cli memory -s $SESSION "0x7fffffffe000" --size 64
# Disassembly
gdb-cli disasm -s $SESSION --count 20
# Check all threads (for deadlock analysis)
gdb-cli thread-apply -s $SESSION bt --all
# View shared libraries
gdb-cli sharedlibs -s $SESSION
Step 5: Session Management
# List active sessions
gdb-cli sessions
# Check session status
gdb-cli status -s $SESSION
# Stop session (cleanup)
gdb-cli stop -s $SESSION
Common Debugging Patterns
Pattern: Null Pointer Dereference
Indicators:
- Crash on memory access instruction
- Pointer variable is 0x0
Investigation:
gdb-cli registers -s $SESSION # Check RIP
gdb-cli eval-cmd -s $SESSION "ptr" # Check pointer value
Pattern: Deadlock
Indicators:
- Multiple threads stuck in lock functions
pthread_mutex_lockin backtrace
Investigation:
gdb-cli thread-apply -s $SESSION bt --all
# Look for circular wait patterns
Pattern: Memory Corruption
Indicators:
- Crash in malloc/free
- Garbage values in variables
Investigation:
gdb-cli memory -s $SESSION "&variable" --size 128
gdb-cli registers -s $SESSION
Examples
Example 1: Core Dump Analysis
# Load core dump
gdb-cli load --binary ./myapp --core /tmp/core.1234
# Get crash location
gdb-cli bt -s a1b2c3 --full
# Examine crash frame
gdb-cli locals-cmd -s a1b2c3 --frame 0
Example 2: Live Process Debugging
# Attach to stuck server
gdb-cli attach --pid 12345
# Check all threads
gdb-cli threads -s b2c3d4
# Get all backtraces
gdb-cli thread-apply -s b2c3d4 bt --all
Best Practices
- Always read source code before drawing conclusions from variable values
- Use
--rangefor pagination on large thread counts or deep backtraces - Use
ptypeto understand complex data structures before examining values - Check all threads for multi-threaded issues
- Cross-reference types with source code definitions
Security & Safety Notes
- This skill requires GDB access to processes and core dumps
- Attaching to processes may require appropriate permissions (sudo, ptrace_scope)
- Core dumps may contain sensitive data - handle with care
- Only debug processes you have authorization to analyze
Related Skills
@systematic-debugging- General debugging methodology@test-driven-development- Write tests before implementation
Links
- Repository: https://github.com/Cerdore/gdb-cli
- PyPI: https://pypi.org/project/gdb-cli/
- Documentation: https://github.com/Cerdore/gdb-cli#readme
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.