1. ドキュメント
2. GDBでGoコードをデバッグする

GDBでGoコードをデバッグする

以下の手順は標準ツールチェーン（gc Goコンパイラとツール）に適用されます。Gccgoはネイティブのgdbサポートを備えています。

標準ツールチェーンでビルドされたGoプログラムをデバッグする場合、DelveはGDBよりも優れた代替手段であることに注意してください。Goランタイム、データ構造、式をGDBよりもよく理解しています。Delveは現在、amd64上のLinux、OSX、Windowsをサポートしています。サポートされているプラットフォームの最新リストについては、Delveのドキュメントを参照してください。

GDBはGoプログラムをうまく理解できません。スタック管理、スレッド処理、ランタイムには、GDBが想定する実行モデルとは十分に異なる側面が含まれているため、デバッガを混乱させ、gccgoでコンパイルされたプログラムであっても誤った結果を引き起こす可能性があります。結果として、GDBは一部の状況（Cgoコードのデバッグ、ランタイム自体のデバッグなど）では有用である可能性がありますが、Goプログラム、特に並行処理の多いプログラムの信頼できるデバッガではありません。さらに、これらの困難な問題に対処することはGoプロジェクトの優先事項ではありません。

つまり、以下の手順は、GDBが機能する場合の使い方のガイドとしてのみ解釈されるべきであり、成功を保証するものではありません。この概要以外にも、GDBマニュアルを参照することをお勧めします。

はじめに

Linux、macOS、FreeBSD、またはNetBSDでgcツールチェーンを使用してGoプログラムをコンパイルおよびリンクすると、結果として得られるバイナリには、GDBデバッガの最近のバージョン（≥7.5）がライブプロセスまたはコアダンプを検査するために使用できるDWARFv4デバッグ情報が含まれます。

リンカーに'-w'フラグを渡してデバッグ情報を省略します（例：go build -ldflags=-w prog.go）。

gcコンパイラによって生成されるコードには、関数呼び出しのインライン化と変数のレジスタ化が含まれます。これらの最適化は、gdbでのデバッグを困難にすることがあります。これらの最適化を無効にする必要がある場合は、go build -gcflags=all="-N -l"を使用してプログラムをビルドしてください。

gdbを使用してコアダンプを検査したい場合は、環境変数にGOTRACEBACK=crashを設定することで、許可されているシステムでプログラムクラッシュ時にダンプをトリガーできます（詳細については、ランタイムパッケージのドキュメントを参照してください）。

一般的な操作

• コードのファイルと行番号を表示し、ブレークポイントを設定し、逆アセンブルする

  (gdb) list
  (gdb) list line
  (gdb) list file.go:line
  (gdb) break line
  (gdb) break file.go:line
  (gdb) disas

• バックトレースを表示し、スタックフレームを巻き戻す

  (gdb) bt
  (gdb) frame n

• ローカル変数、引数、戻り値の名前、型、スタックフレーム上の場所を表示する

  (gdb) info locals
  (gdb) info args
  (gdb) p variable
  (gdb) whatis variable

• グローバル変数の名前、型、場所を表示する

  (gdb) info variables regexp

Go拡張

GDBへの最近の拡張メカニズムにより、特定のバイナリの拡張スクリプトをロードできるようになりました。ツールチェーンはこれを利用して、ランタイムコードの内部（ゴルーチンなど）を検査したり、組み込みのマップ、スライス、チャネル型を整形表示したりするためのいくつかのコマンドでGDBを拡張しています。

• 文字列、スライス、マップ、チャネル、またはインターフェースの整形表示

  (gdb) p var

• 文字列、スライス、マップ用の$len()および$cap()関数

  (gdb) p $len(var)

• インターフェースを動的型にキャストする関数

  (gdb) p $dtype(var)
  (gdb) iface var

  既知の問題：GDBは、インターフェース値の長い名前が短い名前と異なる場合、その動的型を自動的に見つけることができません（スタックトレースを印刷するときに煩わしく、整形表示機能は短い型名とポインタを印刷することにフォールバックします）。

• ゴルーチンの検査

  (gdb) info goroutines
  (gdb) goroutine n cmd
  (gdb) help goroutine

  例

  (gdb) goroutine 12 bt

  特定のゴルーチンのIDの代わりにallを渡すことで、すべてのゴルーチンを検査できます。例

  (gdb) goroutine all bt

これがどのように機能するかを確認したい場合、または拡張したい場合は、Goソース配布のsrc/runtime/runtime-gdb.pyを参照してください。これは、リンカー（src/cmd/link/internal/ld/dwarf.go）がDWARFコードに記述されていることを保証するいくつかの特殊なマジック型（hash<T,U>）と変数（runtime.mおよびruntime.g）に依存しています。

デバッグ情報がどのように見えるかに関心がある場合は、objdump -W a.outを実行し、.debug_*セクションを参照してください。

既知の問題

1. 文字列の整形表示は、型stringに対してのみトリガーされ、それから派生した型に対してはトリガーされません。
2. ランタイムライブラリのC部分には型情報が欠落しています。
3. GDBはGoの名前修飾を理解せず、"fmt.Print"を"."を含む非構造化リテラルとして扱い、引用符で囲む必要があるとみなします。pkg.(*MyType).Methのような形式のメソッド名には、さらに強く異議を唱えます。
4. Go 1.11以降、デバッグ情報はデフォルトで圧縮されます。MacOSでデフォルトで利用可能なGDBの古いバージョンなどでは、この圧縮を理解できません。非圧縮のデバッグ情報を生成するには、go build -ldflags=-compressdwarf=falseを使用します。（便宜上、この-ldflagsオプションをGOFLAGS環境変数に入れることで、毎回指定する必要がなくなります。）

チュートリアル

このチュートリアルでは、regexpパッケージの単体テストのバイナリを検査します。バイナリをビルドするには、$GOROOT/src/regexpに移動し、go test -cを実行します。これにより、regexp.testという名前の実行可能ファイルが生成されます。

はじめに

GDBを起動し、regexp.testをデバッグする

$ gdb regexp.test
GNU gdb (GDB) 7.2-gg8
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv  3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
Type "show copying" and "show warranty" for licensing/warranty details.
This GDB was configured as "x86_64-linux".

Reading symbols from  /home/user/go/src/regexp/regexp.test...
done.
Loading Go Runtime support.
(gdb)

「Loading Go Runtime support」というメッセージは、GDBが$GOROOT/src/runtime/runtime-gdb.pyから拡張機能をロードしたことを意味します。

GDBがGoランタイムソースと付随するサポートスクリプトを見つけられるように、'-d'フラグで$GOROOTを渡します

$ gdb regexp.test -d $GOROOT

何らかの理由でGDBがそのディレクトリまたはスクリプトをまだ見つけられない場合は、gdbに手動でロードするよう指示できます（Goソースが~/go/にあると仮定して）

(gdb) source ~/go/src/runtime/runtime-gdb.py
Loading Go Runtime support.

ソースの検査

"l"または"list"コマンドを使用してソースコードを検査します。

(gdb) l

関数名で"list"をパラメータ化してソースの特定の箇所をリストします（パッケージ名で修飾する必要があります）。

(gdb) l main.main

特定のファイルと行番号をリストする

(gdb) l regexp.go:1
(gdb) # Hit enter to repeat last command. Here, this lists next 10 lines.

命名

変数名と関数名は、それらが属するパッケージ名で修飾する必要があります。regexpパッケージのCompile関数は、GDBには'regexp.Compile'として知られています。

メソッドは、そのレシーバ型の名前で修飾する必要があります。例えば、*Regexp型のStringメソッドは'regexp.(*Regexp).String'として知られています。

他の変数をシャドウする変数は、デバッグ情報内で数字が魔法のようにサフィックスとして付加されます。クロージャによって参照される変数は、魔法のように「&」がプレフィックスとして付加されたポインタとして表示されます。

ブレークポイントの設定

TestFind関数にブレークポイントを設定する

(gdb) b 'regexp.TestFind'
Breakpoint 1 at 0x424908: file /home/user/go/src/regexp/find_test.go, line 148.

プログラムを実行する

(gdb) run
Starting program: /home/user/go/src/regexp/regexp.test

Breakpoint 1, regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/regexp/find_test.go:148
148	func TestFind(t *testing.T) {

実行がブレークポイントで一時停止しました。どのゴルーチンが実行中で、何をしているかを確認してください

(gdb) info goroutines
  1  waiting runtime.gosched
* 13  running runtime.goexit

*でマークされているのは現在のゴルーチンです。

スタックの検査

プログラムが一時停止した場所のスタックトレースを確認する

(gdb) bt  # backtrace
#0  regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/regexp/find_test.go:148
#1  0x000000000042f60b in testing.tRunner (t=0xf8404a89c0, test=0x573720) at /home/user/go/src/testing/testing.go:156
#2  0x000000000040df64 in runtime.initdone () at /home/user/go/src/runtime/proc.c:242
#3  0x000000f8404a89c0 in ?? ()
#4  0x0000000000573720 in ?? ()
#5  0x0000000000000000 in ?? ()

もう1つのゴルーチン、番号1はruntime.goschedで停止しており、チャネル受信でブロックされています

(gdb) goroutine 1 bt
#0  0x000000000040facb in runtime.gosched () at /home/user/go/src/runtime/proc.c:873
#1  0x00000000004031c9 in runtime.chanrecv (c=void, ep=void, selected=void, received=void)
 at  /home/user/go/src/runtime/chan.c:342
#2  0x0000000000403299 in runtime.chanrecv1 (t=void, c=void) at/home/user/go/src/runtime/chan.c:423
#3  0x000000000043075b in testing.RunTests (matchString={void (struct string, struct string, bool *, error *)}
 0x7ffff7f9ef60, tests=  []testing.InternalTest = {...}) at /home/user/go/src/testing/testing.go:201
#4  0x00000000004302b1 in testing.Main (matchString={void (struct string, struct string, bool *, error *)}
 0x7ffff7f9ef80, tests= []testing.InternalTest = {...}, benchmarks= []testing.InternalBenchmark = {...})
at /home/user/go/src/testing/testing.go:168
#5  0x0000000000400dc1 in main.main () at /home/user/go/src/regexp/_testmain.go:98
#6  0x00000000004022e7 in runtime.mainstart () at /home/user/go/src/runtime/amd64/asm.s:78
#7  0x000000000040ea6f in runtime.initdone () at /home/user/go/src/runtime/proc.c:243
#8  0x0000000000000000 in ?? ()

スタックフレームは、期待どおりにregexp.TestFind関数が現在実行中であることを示しています。

(gdb) info frame
Stack level 0, frame at 0x7ffff7f9ff88:
 rip = 0x425530 in regexp.TestFind (/home/user/go/src/regexp/find_test.go:148);
    saved rip 0x430233
 called by frame at 0x7ffff7f9ffa8
 source language minimal.
 Arglist at 0x7ffff7f9ff78, args: t=0xf840688b60
 Locals at 0x7ffff7f9ff78, Previous frame's sp is 0x7ffff7f9ff88
 Saved registers:
  rip at 0x7ffff7f9ff80

info localsコマンドは、関数内のすべてのローカル変数とその値をリストしますが、初期化されていない変数も出力しようとするため、使用には少し危険が伴います。初期化されていないスライスは、gdbが任意に大きな配列を出力しようとする原因となる可能性があります。

関数の引数

(gdb) info args
t = 0xf840688b60

引数を出力すると、それがRegexp値へのポインタであることに注目してください。GDBが誤って*を型名の右側に配置し、伝統的なCスタイルで「struct」キーワードを作り出していることに注意してください。

(gdb) p re
(gdb) p t
$1 = (struct testing.T *) 0xf840688b60
(gdb) p t
$1 = (struct testing.T *) 0xf840688b60
(gdb) p *t
$2 = {errors = "", failed = false, ch = 0xf8406f5690}
(gdb) p *t->ch
$3 = struct hchan<*testing.T>

そのstruct hchan<*testing.T>は、チャネルのランタイム内部表現です。現在は空であり、そうでなければgdbはその内容を整形表示していたでしょう。

前進する

(gdb) n  # execute next line
149             for _, test := range findTests {
(gdb)    # enter is repeat
150                     re := MustCompile(test.pat)
(gdb) p test.pat
$4 = ""
(gdb) p re
$5 = (struct regexp.Regexp *) 0xf84068d070
(gdb) p *re
$6 = {expr = "", prog = 0xf840688b80, prefix = "", prefixBytes =  []uint8, prefixComplete = true,
  prefixRune = 0, cond = 0 '\000', numSubexp = 0, longest = false, mu = {state = 0, sema = 0},
  machine =  []*regexp.machine}
(gdb) p *re->prog
$7 = {Inst =  []regexp/syntax.Inst = {{Op = 5 '\005', Out = 0, Arg = 0, Rune =  []int}, {Op =
    6 '\006', Out = 2, Arg = 0, Rune =  []int}, {Op = 4 '\004', Out = 0, Arg = 0, Rune =  []int}},
  Start = 1, NumCap = 2}

"s"でString関数呼び出しにステップインできます

(gdb) s
regexp.(*Regexp).String (re=0xf84068d070, noname=void) at /home/user/go/src/regexp/regexp.go:97
97      func (re *Regexp) String() string {

現在の位置を確認するためにスタックトレースを取得する

(gdb) bt
#0  regexp.(*Regexp).String (re=0xf84068d070, noname=void)
    at /home/user/go/src/regexp/regexp.go:97
#1  0x0000000000425615 in regexp.TestFind (t=0xf840688b60)
    at /home/user/go/src/regexp/find_test.go:151
#2  0x0000000000430233 in testing.tRunner (t=0xf840688b60, test=0x5747b8)
    at /home/user/go/src/testing/testing.go:156
#3  0x000000000040ea6f in runtime.initdone () at /home/user/go/src/runtime/proc.c:243
....

ソースコードを見る

(gdb) l
92              mu      sync.Mutex
93              machine []*machine
94      }
95
96      // String returns the source text used to compile the regular expression.
97      func (re *Regexp) String() string {
98              return re.expr
99      }
100
101     // Compile parses a regular expression and returns, if successful,

整形表示

GDBの整形表示メカニズムは、型名に対する正規表現の一致によってトリガーされます。スライスの例

(gdb) p utf
$22 =  []uint8 = {0 '\000', 0 '\000', 0 '\000', 0 '\000'}

スライス、配列、文字列はCポインタではないため、GDBは添字操作を解釈できませんが、ランタイム表現の内部を調べることでそれを行うことができます（ここでタブ補完が役立ちます）

(gdb) p slc
$11 =  []int = {0, 0}
(gdb) p slc-><TAB>
array  slc    len
(gdb) p slc->array
$12 = (int *) 0xf84057af00
(gdb) p slc->array[1]
$13 = 0

拡張関数$lenと$capは、文字列、配列、スライスで機能します

(gdb) p $len(utf)
$23 = 4
(gdb) p $cap(utf)
$24 = 4

チャネルとマップは「参照」型であり、gdbはC++のような型hash<int,string>*へのポインタとして表示します。間接参照すると整形表示がトリガーされます

インターフェースは、ランタイムでは型記述子へのポインタと値へのポインタとして表現されます。Go GDBランタイム拡張機能はこれをデコードし、ランタイム型に対して自動的に整形表示をトリガーします。拡張関数$dtypeは、動的型をデコードします（例はregexp.goの293行目のブレークポイントから取得されています）。

(gdb) p i
$4 = {str = "cbb"}
(gdb) whatis i
type = regexp.input
(gdb) p $dtype(i)
$26 = (struct regexp.inputBytes *) 0xf8400b4930
(gdb) iface i
regexp.input: struct regexp.inputBytes *