やりたいこと

CSVファイルの一般的書式 (RFC4180 日本語訳)より

(レコード中の) 各フィールドは、それぞれダブルクォーテーションで囲んでも囲わなくてもよい

とあるので、プロジェクトによってはダブルクォーテーションで囲っておこうぜ！ってなることもあると思います。私のところもそうでした。

なのでタイトル通りgolangでcsvの各要素をダブルクォーテーションでくくろう！というのが、今回やりたいことになります。

しかし、golangの標準csv encoderだと、必ず"にはエスケープ文字として"が付くため、"column" → """column""" になってしまうんですよね。さてどうしたもんか

結論

基本はgocsvを利用します。
こんなencode処理、こういう出力になります。

client_id,client_name,client_age
12,John,21
13,Fred,
14,James,32
15,Danny,

コード全文

base.go

package main

import (
    "fmt"
    "bytes"

    "github.com/gocarina/gocsv"
)

type Client struct { // Our example struct, you can use "-" to ignore a field
    Id      string `csv:"client_id"`
    Name    string `csv:"client_name"`
    Age     string `csv:"client_age"`
    NotUsed string `csv:"-"`
}

//base data
func basedata() []*Client {
    clients := []*Client{}
    clients = append(clients, &Client{Id: "12", Name: "John", Age: "21"}) // Add clients
    clients = append(clients, &Client{Id: "13", Name: "Fred"})
    clients = append(clients, &Client{Id: "14", Name: "James", Age: "32"})
    clients = append(clients, &Client{Id: "15", Name: "Danny"})
    return clients
}

func main() {
    clients := basedata()
    out := bytes.Buffer{}
    err := gocsv.Marshal(&clients, &out) // Get all clients as CSV string
    if err != nil {
        panic(err)
    }
    csvContent := out.Bytes()
    fmt.Println(string(csvContent)) // Display all clients as CSV string

}

encode前のこちらの各要素にいくら"をくっつけてもMarshalで"""に変えられてしまうので、発想を変えます。
一旦encodeしたbyte列をdecodeすると要素毎にstringで取れるので、そこに"をくっつけます。

gocsvでは区切り文字や改行コードの制御ができるので、そこから取ってきます。

デフォルトでは gocsv.DefaultCSVWriter を実行して取得できる gocsv.SafeCSVWriter の値なので、,。改行コードは¥nです。

こちらの情報はgocsv.SetCSVWriterで変更されるかもしれませんので、そこは実装に合わせて変えてください。

サンプルはこちら、処理を抜粋。Gist

base.go

//Marshalの第二引数をそのままこちらに渡す
func convert(b *bytes.Buffer) ([]byte, error) {
        //retry to decode, to check ""
        reader := csv.NewReader(b)
        reader.LazyQuotes = true
        lines, err := reader.ReadAll()
        if err != nil {
                return []byte{}, err
        }

        //rewrite to add "", escape \"
        bytes := make([]byte, 0, len(b.Bytes())*2)

        //If you update writer by SetCSVWriter, please change the delimiter which you use
        delimiter := ','
        //If you update writer by SetCSVWriter, please change the crlf which you use
        for _, line := range lines {
                for i, part := range line {
                        if i != 0 {
                                bytes = append(bytes, byte(delimiter))
                        }
                        bytes = append(bytes, []byte(escape(part))...)
                }
                bytes = append(bytes, byte('\r'))
        }
        return bytes, nil
}

func escape(part string) string {
        //"XXX" => XXX
        escapeStr := strings.Replace(part, "\"", "\"\"", -1)
        return "\"" + escapeStr + "\""
}

実行結果。tagはそのままにしたい場合は、convert内のlinesループを調整して最初をスキップすればOKです

"client_id","client_name","client_age"
"12","John","21"
"13","Fred",""
"14","James","32"
"15","Danny",""

おまけ

おまけ 結論に至るまでの経緯

golangでのcsv実装に苦しんだおっさんのサタデーナイトをお楽しみください

きっかけ: 「csvのダブルクォーテーションが扱えてません！」という話があったので、調査をした

参考記事をヒントに、エンコーダーのどこかでラップしてあげるのが手なんだろうなーと思いみていく
以下泥沼調査の流れになります

• gocsv内でSetCSVWriterを利用して、io.Writerや encoding/csv のcsv.Writerは上書きできないのだろうか？
  • io.Writerはbyte列の制御を行うので、ここに自作をかますのはもうcsvのパーサーを独自自作するのと変わらない。却下
  • encoding/csv側はinterfaceではなく内部で定義した構造体をやりとりしてるので、golangの仕様的に上書きは無理
  • →この案はダメ！
• 逆にgocsvが使っているwriterを変えて、色々処理を実行して"追加ができないか？
  • gocsvでCSVWriterというinterfaceを定義しているぞ！使えそう！
    • いや、SetCSVWriterでwriterの生成関数を登録することは可能なんだけど、関数の引数がCSVWriterじゃなくて*SafeCSVWriter。型が合わない。。。
    • ん、でもgocsvの使い方としてはSafeCSVWriterをCSVWriterのinterface以外で使ってないぞ！CSVWriterに定義変えても動くのでは？
    • forkしてCSVWriter上書き試してみよう。お、いけるやん！
    • ダブルクォーテーションのサンプルコードも詰め込んじゃお！公式取り入れてくれたら最高だよなー、まあいいや。CSVWriterも自作したものを動かして、実際のケースでテスト書くか
    • うわ、これで設定したダブルクォーテーションまでエスケープされてるやんけ！
    • ここまでは良さそうだけど、解決まではいけないらしい
  • gocsvのdecodeは"の扱いうまいし要素単位のデータが取れるぞ！
    • そしたら上でやったダブルクォーテーションのコードをcolumn単位で取り出してあげればエスケープなしの文字が取れるな！これを使って[]byteに書き込んで再構築すればいいんじゃないか？
    • うん、できるな。文字列中の"もエスケープが抜けてるからそれを追加しよう！
    • よし！うまく行ったぜ！一休みしたらgocsvにPR出して解決だ！
    • 、、、あれ、CSVWriterいじったの無意味じゃね？

という、結果無駄に終わる公式コードのデバッグと修正を行ったサタデーナイトフィーバーでした

頑張った痕跡をPR出そうか迷ったんですが、ユースケースがゼロになったので出す価値ないなと思い保留。代わりにこの記事とGistを書き留めるに至りました

参考

CSVファイルの一般的書式 (RFC4180 日本語訳)
4.1.6　CSV形式の記述規則
golangでCSV出力時、要素をダブルクオートでくくることができない
gocsv 公式

この記事は Chapter I: A Primer on Go Assembly を翻訳、加筆したものです。

この記事では以下のような人を想定しています。

• Go言語の文法を理解している
• サブルーチンコール時の一般的なスタックの挙動を理解している

環境

$ go version
go version go1.10 linux/amd64

擬似アセンブリ

Goコンパイラが出力するアセンブリは、抽象化されたものであり、実際のハードウェアにマッピングされていません。 Goアセンブラはこの擬似アセンブリを対象のハードウェアに沿った機械語に変換します。

Javaのバイトコードのようなものを想像するとわかりやすいかもしれません。

このような中間層を設けることの最大の利点は新しいアーキテクチャに対応するのが楽になることです。
詳細を知りたい場合は、Rob Pike氏著の The Design of the Go Assemblerを見てください。

Goアセンブリを知るためにもっとも重要なことは、Goアセンブリが対象のハードウェアと直接対応していないという事実です。 一部分はハードウェアと直接結びついていますが、そうでないものもあります。これによってコンパイラはパイプライン上でアセンブラPassを必要とすることがなくなり、代わりに、コンパイラはこのハードウェアを抽象化した擬似アセンブリを扱えばよく、Instruction selection(この場合は、Goアセンブリから実際のアセンブリへの変換を指す)はcode generation(コンパイラによるGoアセンブリの生成のこと)の後で部分的に行われるようになっています。擬似アセンブリの例として、GOアセンブリのMOV命令は clear や load 命令などに変換されることもあればアーキテクチャによっては(名前は変わるかもしれないが)そのままのこともあります。メモリのデータ移動やサブルーチンのコールやリターンなどのアーキテクチャに共通する概念が抽象化される一方で、ハードウェアに特有な命令はそのまま表されることが多いです。

Goアセンブラはこの擬似アセンブリをパースして、リンカの入力となるよう命令に変換するプログラムです。

単純なプログラムを用いた例

次のコードを考えて見ましょう。

//go:noinline
func add(a, b int32) (int32, bool) { return a + b, true }

func main() { add(10, 32) }

(//go:noinline インライン展開をしないようにするためのディレクティブ)

このコードをアセンブリにコンパイルしてみましょう。

$ GOOS=linux GOARCH=amd64 go tool compile -S direct_topfunc_call.go

0x0000 TEXT     "".add(SB), NOSPLIT, $0-16
  0x0000 FUNCDATA   $0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB)
  0x0000 FUNCDATA   $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
  0x0000 MOVL       "".b+12(SP), AX
  0x0004 MOVL       "".a+8(SP), CX
  0x0008 ADDL       CX, AX
  0x000a MOVL       AX, "".~r2+16(SP)
  0x000e MOVB       $1, "".~r3+20(SP)
  0x0013 RET

0x0000 TEXT     "".main(SB), $24-0
  ;; ...omitted stack-split prologue...
  0x000f SUBQ       $24, SP
  0x0013 MOVQ       BP, 16(SP)
  0x0018 LEAQ       16(SP), BP
  0x001d FUNCDATA   $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
  0x001d FUNCDATA   $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
  0x001d MOVQ       $137438953482, AX
  0x0027 MOVQ       AX, (SP)
  0x002b PCDATA     $0, $0
  0x002b CALL       "".add(SB)
  0x0030 MOVQ       16(SP), BP
  0x0035 ADDQ       $24, SP
  0x0039 RET
  ;; ...omitted stack-split epilogue...

Dissecting add

0x0000 TEXT "".add(SB), NOSPLIT, $0-16

• 0x0000: 命令のオフセット 関数の先頭からの相対位置で表されます。

• TEXT "".add: TEXTディレクティブは"".addシンボルが.textセクションに含まれること、続く命令がこの関数の中身であることを示しています。
  空文字列""はリンク時に現在のパッケージ名に置換されます。今回はmain.addとなります。

• (SB): SBはGoアセンブリで仮想的に定義されたレジスタで、"Static-Base"ポインタのことです。プログラムのアドレス空間の先頭を表しています。
  
  "".add(SB)は"".addシンボルがアドレス空間の先頭からリンカによって計算される一定のオフセットにあることを示しています。言い換えるとアドレスが決まっているグローバルスコープな関数ということです。
  
  objdumpを使うとこのことがよくわかります。

$ objdump -j .text -t direct_topfunc_call | grep 'main.add'
000000000044d980 g     F .text  000000000000000f main.add

objdump補足

• -j .text textセクションのみ表示
• -t シンボルテーブルを表示
• 000000000044d980 g F .text 000000000000000f main.add アドレス0x44d980にmain.addという名前のグローバルな関数シンボルが存在

ユーザーによって定義されたシンボルは全て 擬似レジスタ FP(ローカル)とSB(グローバル) からのオフセットとして記述されます。
擬似レジスタSBはメモリの起点として考えることができるため、foo(SB)シンボルはfooのアドレスを表すシンボルとして考えられます

• NOSPLIT: 現在のスタックを拡張する必要があるか確認する stack-split preambleを挿入しないようにコンパイラに指示しています。
  
  add関数はローカル変数をもたずスタックフレームを必要としないので現在のスタックを拡張する必要はないため、関数呼び出しのたびにスタック拡張の確認を行うことはCPUリソースの無駄遣いです。コンパイラはこのことを自動的に把握して、自動でこのNOSPLITフラグをセットします。スタック拡張については、この後のGoroutineの節で触れています。

• $0-16: $0 はこの関数に割り当てられるスタックフレームのバイト数を、16はcallerによって渡される引数(+返り値)のサイズを表しています。(int32×3 + bool(4byteでalign)で16バイト)

一般的なケースでは、スタックフレームのサイズの後には、マイナス記号で区切られた引数のサイズが続きます。(このマイナス記号は引き算を表しているわけではない) $24-8は、関数に24バイトのスタックフレームがあり、呼び出し元のスタックフレームに存在する8バイトの引数で呼び出されることを示しています。TEXTにNOSPLITが指定されていないときは、引数のサイズは必ず明示する必要があります。Goプロトタイプを使用したアセンブリ関数の場合、go vet は引数のサイズが正しいかのチェックを行います。

0x0000 FUNCDATA $0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB)
0x0000 FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)

FUNCDATA と PCDATA ディレクティブはGCが利用するための情報を含んでいます。

0x0000 MOVL "".b+12(SP), AX
0x0004 MOVL "".a+8(SP), CX

Goの呼び出し規約では、すべての引数はcallerのスタックフレームで事前に確保されたスペースを使ってスタックを通して渡されるようになっています。
よってcalleeに引数を渡し、calleeの返り値がcallerの下に戻ってくるように適切にスタックサイズを管理することはcallerの責任になっています。

Goコンパイラは、 PUSH/POP命令を生成することはありません。代わりに、スタックの先頭をさす擬似レジスタであるSPを足したり引いたりすることでスタックを伸び縮みさせています。

[UPDATE: We've discussed about this matter in issue #21: about SP register.]

擬似レシスタSPはローカル変数や引数を参照するのに利用されます。SPはスタックフレームの先頭を指すので、[−framesize, 0)の範囲の負のオフセットを使って参照を行います。e.g. x-8(SP), y-4(SP)

公式のドキュメントには、ユーザーが定義したシンボルは、FPレジスタからのオフセットで表されると書いてありますが、これは自動的に生成されたコードには当てはまりません。
最近のGoコンパイラは、引数やローカル変数を常にスタックポインタからのオフセットで参照するようになっています。これによってFPは、x86などのレジスタの数が少ないプラットフォームで追加の汎用レジスタとして使うことができるようになりました。
詳細を知りたい方は Stack frame layout on x86-64 を見てください。
[UPDATE: We've discussed about this matter in issue #2: Frame pointer.]

"".b+12(SP) と "".a+8(SP) はそれぞれ、スタックの上から12バイトと8バイトのアドレスを参照しています。（スタックは上位アドレスから下位アドレスに伸びていくことに注意）

.a と .b は参照場所に与えられた任意のエイリアスです。名前は処理内容には影響しませんが、仮想レジスタ上で間接アドレッシングを利用するのに必須です。

擬似フレームポインタであるFPについてのドキュメントには以下のように書かれています。

FPは関数の引数を参照するための仮想のフレームポインタです。コンパイラはこのレジスタの内容を保持し、このレジスタに基づいたオフセットとしてスタック上の関数の引数を参照します。つまり64bitアーキテクチャの場合、 0(FP) は関数の最初の引数を、8(FP)は2番目の引数を指します。しかし、この方法で引数にアクセスするには、first_arg+0(FP)やsecond_arg+8(FP)のように先頭に名前をつけて指定する必要があります。(FPからのオフセットは、シンボルからのオフセットを意味しているSBの場合と異なります) アセンブラは0(FP) と 8(FP)のような名前のない書き方は受け付けずこの名前指定を強制します。実際の名前は処理内容には無関係ですが引数名をドキュメント化するために用いられます。

最後に2点程重要なことがあります。
1. 最初の引数 a は 0(SP) ではなく 8(SP) に配置されます。 これは caller が CALL 命令のときにリターン先のアドレスを 0(SP) に格納しているからです。
2. 引数は後ろのものからスタックにPUSHされていきます。

0x0008 ADDL CX, AX
0x000a MOVL AX, "".~r2+16(SP)
0x000e MOVB $1, "".~r3+20(SP)

ADDL は 2つの Long-words(4バイト長の値) の加算を行いその結果をAXに格納します。ここでは AX と CX の加算を行いその結果を AXに格納しています。
そしてその結果は、callerが返り値を受け取ることを目的に、事前に確保しておいたスタック上の "".~r2+16(SP) に格納されます。ここでも"".~r2には処理内容的には意味は持ちません。

Goは複数の返り値をサポートしているので、この例では定数のtrueも返り値をして返すようにしています。
最初の返り値と同様に、オフセットは異なりますが "".~r3+20(SP) に結果を格納します。

0x0013 RET

最後の擬似命令 RET はGoアセンブラにターゲットとしているハードウェアでサブルーチンから戻るための適切な命令を挿入するように指示するためのものです。
ほとんどの場合、0(SP) に格納したリターン先のアドレスをPOPしてそこにジャンプします。

TEXTブロックの最後の命令は、何かしらのjump命令である必要があります(大抵はRETを用いる)
もしjump命令がない場合、リンカはTEXTブロックを超えて命令を実行しないように自分にjumpする命令を追加します。

文法や解説が大量に出てきたので簡単なまとめを記しておきます。

;; グローバル関数シンボル "".add を宣言(リンク時に main.add)
;; stack-split preambleを挿入しない
;; スタックフレームは0バイト、16バイトの引数が渡される
;; func add(a, b int32) (int32, bool)
0x0000 TEXT "".add(SB), NOSPLIT, $0-16
  ;; ...omitted FUNCDATA stuff...
  0x0000 MOVL   "".b+12(SP), AX     ;; 呼び出し側のスタックフレームからAXに2番目の引数(b)を移動
  0x0004 MOVL   "".a+8(SP), CX      ;; 呼び出し側のスタックフレームからCXに最初の引数(a)を移動
  0x0008 ADDL   CX, AX                ;; AX=CX+AX
  0x000a MOVL   AX, "".~r2+16(SP)   ;; AX に格納された加算結果を呼び出し側のスタックフレームに移動
  0x000e MOVB   $1, "".~r3+20(SP)   ;; 定数`true`を呼び出し側のスタックフレームに移動
  0x0013 RET                            ;; 0(SP) に格納されたリターン先のアドレスにジャンプ

main.addの処理が終了した時のスタックの内容を可視化すると次のようになっています。

   |    +-------------------------+ <-- 32(SP)              
   |    |                         |                         
 G |    |                         |                         
 R |    |                         |                         
 O |    | main.main's saved       |                         
 W |    |     frame-pointer (BP)  |                         
 S |    |-------------------------| <-- 24(SP)              
   |    |      [alignment]        |                         
 D |    | "".~r3 (bool) = 1/true  | <-- 21(SP)              
 O |    |-------------------------| <-- 20(SP)              
 W |    |                         |                         
 N |    | "".~r2 (int32) = 42     |                         
 W |    |-------------------------| <-- 16(SP)              
 A |    |                         |                         
 R |    | "".b (int32) = 32       |                         
 D |    |-------------------------| <-- 12(SP)              
 S |    |                         |                         
   |    | "".a (int32) = 10       |                         
   |    |-------------------------| <-- 8(SP)               
   |    |                         |                         
   |    |                         |                         
   |    |                         |                         
 \ | /  | return address to       |                         
  \|/   |     main.main + 0x30    |                         
   -    +-------------------------+ <-- 0(SP) (TOP OF STACK)

(diagram made with https://textik.com)

Dissecting main

main関数の内容をもう一度おさらいしておきましょう。

func main() { add(10, 32) }

0x0000 TEXT     "".main(SB), $24-0
  ;; ...omitted stack-split prologue...
  0x000f SUBQ       $24, SP
  0x0013 MOVQ       BP, 16(SP)
  0x0018 LEAQ       16(SP), BP
  ;; ...omitted FUNCDATA stuff...
  0x001d MOVQ       $137438953482, AX
  0x0027 MOVQ       AX, (SP)
  ;; ...omitted PCDATA stuff...
  0x002b CALL       "".add(SB)
  0x0030 MOVQ       16(SP), BP
  0x0035 ADDQ       $24, SP
  0x0039 RET
  ;; ...omitted stack-split epilogue...

0x0000 TEXT "".main(SB), $24-0

add関数のときと同様です。今回はスタックフレームに24バイト確保し、引数も受け取らず返り値も特に何も返さないようにしています。

0x000f SUBQ     $24, SP
0x0013 MOVQ     BP, 16(SP)
0x0018 LEAQ     16(SP), BP

もう一度述べますが、Goの呼び出し規約では関数の引数はすべてスタックを通して渡されます。

SPを$24バイト引くことでmainは自身のスタックフレームを24バイト確保しています。(スタックが下方向に伸びることに注意してください)

この確保した$24バイトは以下のように使います。

• 8 bytes (16(SP)-24(SP)) は フレームポインタBP の現在の値を保存するのに使われます。これによってスタックの巻き戻し(呼び出し下の関数を辿ること)が可能になりデバッグ時に便利です。 (MOVQ BP, 16(SP))
• 1+3 bytes (12(SP)-16(SP)) は add関数 の2番目の返り値を受け取るために確保されています (boolは1バイトだがamd64アーキテクチャのアラインメントのため+3バイト)
• 4 bytes (8(SP)-12(SP)) は add関数 の1番目の返り値を受け取るために確保されています (int32)
• 4 bytes (4(SP)-8(SP)) は add関数の 引数の値のために確保されています b (int32)
• 4 bytes (0(SP)-4(SP)) は add関数の 引数の値のために確保されています a (int32)

最後に、スタックの確保に続いて、 LEAQはフレームポインタの新しいアドレスを計算し、それをBPに格納します。(x86のlea命令と同様に BP = 16(SP))

0x001d MOVQ     $137438953482, AX
0x0027 MOVQ     AX, (SP)

caller は callee のための引数を8byteのQuad-wordとしてスタックの先頭に配置しています。
配置している値は一見すると意味のない値に見えますが、137438953482 は 4バイトの10 と 32 をひとまとめにして表しています。

$ echo 'obase=2;137438953482' | bc
10000000000000000000000000000000001010
\____/\______________________________/
   32                              10

137438953482 の上位32-63bitが 100000(32)、下位0-31bitが 00000000000000000000000000001010(10) を表しています。

0x002b CALL     "".add(SB)

SBからの相対オフセットとして add関数 を CALL命令 で呼び出します。

CALLはリターン先のアドレスとして8byteのアドレスをスタックの先頭に配置するので、｀add｀関数 内で参照している SP はすべて8byte下にシフトされることに注意しましょう。

例えば、"".a は 0(SP) でなく 8(SP) と表されます。

0x0030 MOVQ     16(SP), BP
0x0035 ADDQ     $24, SP
0x0039 RET

最後に、

1. フレームレジスタを巻き戻す MOVQ 16(SP), BP
2. 確保したスタックフレームを解放する ADDQ $24, SP
3. リターン

して main関数の実行を終えます

addとmainを通して、やっていることは一般的なサブルーチンコールだと思います。

Goroutineのスタック管理

Goroutineに関するアセンブリを見ていけば、スタック管理に関する命令に一気に馴染めるでしょう。

これらのパターンをなるべく早く理解できるように、ここでは、何をしているのか、なぜこのようなことをしているのかを理解しましょう。

Stacks

Goプログラム中に現れるGoroutineの数は状況によって異なります。実用的なプログラムでは数百万に及ぶこともあるかもしれません。Goのランタイムは、メモリを使い尽くしてしまわないように、Goroutineのスタックの確保には保守的な方法をとっています。
どんなGoroutineも最初は2KBのスタック空間がランタイムによって割り当てられます。(スタックは実際にはバックグラウンドでヒープに割り当てられます)

Goroutineが実行される時、場合によっては最初に割り当てられた2KBより多くのメモリが必要になるかもしれません。その場合、スタックを破壊して他のメモリ領域に侵入してしまうかもしれません。
このようなスタックオーバーフローを防ぐために、ランタイムはGoroutineがスタックを超えそうなときに、従来の2倍の大きさのスタックを確保して、そこにスタックの内容をコピーします。
このプロセスは stack-split と呼ばれており、Goroutineのスタックサイズを効率よく動的に扱えるようにしています。

Splits

stack-splitが機能するように、コンパイラはスタックオーバーフローが起きるかもしれない各関数の最初と最後にいくつかの命令を挿入してスタックオーバーフローが起きたことをチェックできるようにしています。
最初の方で見たようにスタックオーバーフローが起こり得ない関数ではこの処理は無駄なので、NOSPLIT によってコンパイラにチェックする命令の挿入の必要がないことを伝えることができます。

上のmain関数では stack-split に関するコードの説明は省きましたが、今度は省略せずに見てみましょう。

0x0000 TEXT "".main(SB), $24-0
  ;; stack-split prologue
  0x0000 MOVQ   (TLS), CX
  0x0009 CMPQ   SP, 16(CX)
  0x000d JLS    58

  0x000f SUBQ   $24, SP
  0x0013 MOVQ   BP, 16(SP)
  0x0018 LEAQ   16(SP), BP
  ;; ...omitted FUNCDATA stuff...
  0x001d MOVQ   $137438953482, AX
  0x0027 MOVQ   AX, (SP)
  ;; ...omitted PCDATA stuff...
  0x002b CALL   "".add(SB)
  0x0030 MOVQ   16(SP), BP
  0x0035 ADDQ   $24, SP
  0x0039 RET

  ;; stack-split epilogue
  0x003a NOP
  ;; ...omitted PCDATA stuff...
  0x003a CALL   runtime.morestack_noctxt(SB)
  0x003f JMP    0

• 関数の最初(prologue)でGoroutineがスタックを使い切っているかチェックし、その場合は関数の最後(epilogue)にジャンプしています。
• 関数の最後(epilogue)では、スタック拡張の処理をトリガーして、それが終わった後、関数の最初(prologue)に戻ります。

このprologueとepilogueはスタックサイズが十分な大きさになるまでループし続けることに注意してください。

Prologue

0x0000 MOVQ (TLS), CX   ;; store current *g in CX
0x0009 CMPQ SP, 16(CX)  ;; compare SP and g.stackguard0
0x000d JLS  58          ;; jumps to 0x3a if SP <= g.stackguard0

TLSはランタイムによって管理される仮想のレジスタで現在のgを指すポインタを持っています。これは、Goroutineの全ての状態をトレースするデータ構造です。

ランタイムのソースコードから g の定義を確認してみましょう。

type g struct {
    stack       stack   // 16 bytes
  // stackguard0 は Prologueで比較対象となるスタックポインタ
  // 通常、stackgurad0は stack.lo+StackGuard となるが、プリエンプションをトリガーするために StackPreempt になる可能性もある
  // プリエンプション: マルチタスクのコンピュータシステムが実行中のタスクを一時的に中断する動作
    stackguard0 uintptr
    stackguard1 uintptr

    // ...omitted dozens of fields...
}

g.stackが16バイトなので、16(CX) は g.stackguard0 となります。これはランタイムによって管理されているスタックの閾値で、スタックポインタと比較するとGoroutineがスタック空間を使い切ってしまったかを確認できます。

スタックは下位アドレス方向に伸びていくので、 SP <= stackguard0 ならばスタック空間を使い切っていることになります。その場合、prologueは epilogueにジャンプします。

Epilogue

0x003a NOP
0x003a CALL runtime.morestack_noctxt(SB)
0x003f JMP  0

epilogueの処理は簡単で、ランタイムのスタック拡張関数をコールしてスタックを拡張し、prologueのコードに戻るだけです。

CALL の前の NOP は prologueのコードが CALL に直接ジャンプしないようにするために存在しています。プラットフォームによってはかなり深い部分まで解説する必要が出てくるので説明は省きますが、CALL命令の前にNOP命令を置いてそこにジャンプすることは共通のプラクティスとなっています。
[UPDATE: We've discussed about this matter in issue #4: Clarify "nop before call" paragraph.]

今回説明したのは氷山の一角にすぎません。

スタック拡張のメカニズムはここでは説明しきれないほど細かく複雑なので機会があればそれ専用の章を設けたいと思っています。

まとめ

今回はGo Assemblyを単純な例を用いて解説してみました。

残りの章でGoの内部実装をさらに掘り進めていきます。