Go言語におけるIf文
Go言語におけるIf文
まず、我々がGoを選択した理由は、Goがモダンな言語の中では最もアセンブリが「美しく」、古典的な言語と比較してもその構文の効率性が圧倒的である場合が多々あるためです。
前回の講義でGoプログラムの基本的な動作原理について理解しましたので、早速GoとAssemblyを一行ずつ比較してみましょう。
ソースコード
まず、Goにおいても同様ですが、GCCを含むモダンなコンパイラは、使用される意義のない分岐文を自動的に最適化します。GCCやClangといったC言語のコンパイラも、業界標準である-O2において非常に攻撃的な最適化を行うため、プログラマがコンパイラを完全に信頼することが難しい時代は、20世紀後半から既に完成していると言えます。
したがって、コンパイラの視点から見て予測し、別の構文に置換することが困難な条件を与えることで、初めてコードに意味が生まれます。
1package main
2
3import (
4 "os"
5 "strconv"
6)
7
8func main() {
9 // もしこれを x = 10 のような予測可能で分岐を削除できるもので埋めると、
10 // コンパイラが最適化を行い分岐を削除します。
11 // したがって、このようなものを直接アセンブリで確認するには、C言語では -O0 等を指定するか、
12 // そもそもコンパイラが予測不可能な外部値を使用させる必要がありますが、
13 // このセクションではモダンなプログラミングを扱うため、Goのバイナリ最適化を
14 // 無効にする手法は使用しません。
15 if len(os.Args) < 2 {
16 return
17 }
18 x, _ := strconv.Atoi(os.Args[1])
19
20 if x < 10 {
21 println("X is smaller than 10")
22 } else {
23 println("X is larger or same as 10")
24 }
25}
この場合、入力内容をコンパイラが予測できないため、分岐文はそのまま機械語に翻訳されます。
アセンブリ言語
1TEXT main.main(SB) /home/yjlee/introduction-to-golang/learn-golang/if-and-switch/golang-if/main.go
2 main.go:8 0x47a840 493b6610 CMPQ SP, 0x10(R14)
3 main.go:8 0x47a844 7670 JBE 0x47a8b6
4 main.go:8 0x47a846 55 PUSHQ BP
5 main.go:8 0x47a847 4889e5 MOVQ SP, BP
6 main.go:8 0x47a84a 4883ec10 SUBQ $0x10, SP
7 main.go:15 0x47a84e 48833d12fb0a0002 CMPQ os.Args+8(SB), $0x2
8 main.go:15 0x47a856 7c58 JL 0x47a8b0
9 main.go:15 0x47a858 488b0d01fb0a00 MOVQ os.Args(SB), CX
10 main.go:18 0x47a85f 488b4110 MOVQ 0x10(CX), AX
11 main.go:18 0x47a863 488b5918 MOVQ 0x18(CX), BX
12 main.go:18 0x47a867 e834e8ffff CALL strconv.Atoi(SB)
13 main.go:20 0x47a86c 4883f80a CMPQ AX, $0xa
14 main.go:20 0x47a870 7d1d JGE 0x47a88f
15 main.go:21 0x47a872 e809befbff CALL runtime.printlock(SB)
16 main.go:21 0x47a877 488d0519f50100 LEAQ 0x1f519(IP), AX
17 main.go:21 0x47a87e bb15000000 MOVL $0x15, BX
18 main.go:21 0x47a883 e878c6fbff CALL runtime.printstring(SB)
19 main.go:21 0x47a888 e853befbff CALL runtime.printunlock(SB)
20 main.go:21 0x47a88d eb1b JMP 0x47a8aa
21 main.go:23 0x47a88f e8ecbdfbff CALL runtime.printlock(SB)
22 main.go:23 0x47a894 488d05c8040200 LEAQ 0x204c8(IP), AX
23 main.go:23 0x47a89b bb1a000000 MOVL $0x1a, BX
24 main.go:23 0x47a8a0 e85bc6fbff CALL runtime.printstring(SB)
25 main.go:23 0x47a8a5 e836befbff CALL runtime.printunlock(SB)
26 main.go:25 0x47a8aa 4883c410 ADDQ $0x10, SP
27 main.go:25 0x47a8ae 5d POPQ BP
28 main.go:25 0x47a8af c3 RET
29 main.go:16 0x47a8b0 4883c410 ADDQ $0x10, SP
30 main.go:16 0x47a8b4 5d POPQ BP
31 main.go:16 0x47a8b5 c3 RET
32 main.go:8 0x47a8b6 e845f0feff CALL runtime.morestack_noctxt.abi0(SB)
33 main.go:8 0x47a8bb eb83 JMP main.main(SB)
go toolを使用すると、どの構文がどのアセンブリに対応しているかを丁寧に示してくれます。
今回学ぶのは比較文とif分岐文であるため、数行に注目すれば十分です。
CMPQ命令 & JL命令
CMPQ命令は4バイト（4ワード）のデータ型を比較するための命令であり、語源は CoMPareQuadwordであるためCMPQと略されています。
0x47a84e番地のメモリを見ると、CMPQ os.Args+8(SB), $0x2という構文が確認できます。この場合、プログラムが受け取った引数の数と16進数の0x2（すなわち2）を比較しています。
その後、引数が2より小さい場合（すなわちプログラム自身のみが引数である場合）、JLを通じて比較後にジャンプを実行します。これは Jump, Less thanを略してJLとなります。先行する比較演算において引数が2より小さかった場合、0x47a8b0番地へジャンプしますが、そこにはJGEが存在します。しかし、この構文で使用されているのはAXレジスタであるため、レジスタに格納された値の正体を把握する必要があります。
MOVQ命令
次に、実際にCXレジスタを使用してデータの開始アドレスを保存し、アドレスを読み取った後の実際のデータをどのように抽出するかを理解する必要があります。
0x47858-0x47863の範囲を見ると、段階的にこの演算が実行されています。
まず、引数配列の開始アドレスをMOVQ os.Args(SB), CX命令でCXレジスタに挿入します。この際、Goの文字列型を理解しておく必要があります。
Goのstringは構造体であり、この構造体は8バイトのデータ2つ、計16バイトで構成されています。
| struct | 8 byte | 8 byte |
|---|---|---|
| string | mem address | string length |
視覚的に描くと上記の通りであり、前方の8バイトには文字列の開始アドレスが、後方の8バイトには文字列の長さが格納されています。
したがって、文字列のアドレスをAXレジスタに、文字列の長さをBXレジスタに格納します。
CALL
前回の投稿でもruntime系の関数を見る際にCALLという命令が付与されていました。これはGoで使用される関数の前に付与されており、何らかの関数を**呼び出す（Call）**という意味です。その後、CALL関数を使用して文字列を整数に変換しますが、この際、整数がどこに格納されるのかは関数に抽象化されており、見えません。
CMPQ命令 & JGE命令
再び先ほどの番地0x47a86cに戻ると、命令は文字列のアドレスと数値である0xa（10進数で10）を比較しています！
これは、プログラム内で該当する引数をもはや使用しないため、文字列のあった位置を上書きして整数型変数 x の領域を確保したことを意味します。
これこそがGo言語等で行われる攻撃的な最適化の実体です。
その後、JGEという命令が登場しますが、これは Jump, Greater or Equalsの略語です。したがって、この構文は比較対象と照らし合わせて「以上」であるかを問うています。
そのため、x < 10という構文そのものではなく、x < 10と構文の比較方向が逆転しています！
これは機械語において、条件が一致しない場合に先制してスキップするほうが、条件が一致した場合の比較を1回実行した後に不一致かどうかを再確認するよりも直感的であり、1つの命令を節約できるためです。
このような最適化は非常に古典的であり、上で見たstrconv.Atoiの例とは異なり、最適化レベルがかなり低いコンパイラでも頻繁に登場するパターンであるため、知っておくと有用です。
したがって、この点を応用すればソースコードは異なっていても、アセンブリ単位では100%一致するソースを得ることが可能です。
鏡像コードの例
以下のスクリプトを使用すると、Bashスクリプトが100%鏡像の二つのソースを作成し、その時々で変化するメタデータを除外してmainのみを比較した場合に、正確に同一のアセンブリが得られることを検証できます。
1#!/usr/bin/env bash
2
3# 1. 既存の残存ファイルおよびディレクトリの完全初期化
4echo "[1/6] Cleaning up old artifacts..."
5rm -rf test_dir main_orig main_asm orig.asm asm.asm orig_pure.asm asm_pure.asm
6mkdir -p test_dir
7
8# 2. オリジナル版ソースコードの作成 (main.go)
9echo "[2/6] Generating main.go..."
10cat << 'EOF' > main.go
11package main
12
13import (
14 "os"
15 "strconv"
16)
17
18func main() {
19 if len(os.Args) < 2 {
20 return
21 }
22 x, _ := strconv.Atoi(os.Args[1])
23
24 s1 := "X is smaller than 10"
25 s2 := "X is larger or same as 10"
26
27 if x < 10 {
28 println(s1)
29 } else {
30 println(s2)
31 }
32}
33EOF
34
35# 3. 鏡像版ソースコードの作成 (main_from_asm.go)
36# コンパイラが最適化テンプレート(JGE)をそのまま使用するように演算子構造を完全に左右対称に同期
37echo "[3/6] Generating main_from_asm.go..."
38cat << 'EOF' > main_from_asm.go
39package main
40
41import (
42 "os"
43 "strconv"
44)
45
46func main() {
47 if len(os.Args) < 2 {
48 return
49 }
50 x, _ := strconv.Atoi(os.Args[1])
51
52 s1 := "X is smaller than 10"
53 s2 := "X is larger or same as 10"
54
55 // 10を基準として x < 10 構造を維持すれば、コンパイラは
56 // main.goと全く同一のJGEメカニズムおよびブロック配置を採用します。
57 if x < 10 {
58 println(s1)
59 } else {
60 println(s2)
61 }
62}
63EOF
64
65# 4. 同一のディレクトリパスおよびファイル名環境下でそれぞれビルドを実行
66echo "[4/6] Compiling both sources inside 'test_dir'..."
67cp main.go test_dir/main.go
68cd test_dir && go build -o ../main_orig main.go && cd ..
69
70rm test_dir/main.go
71cp main_from_asm.go test_dir/main.go
72cd test_dir && go build -o ../main_asm main.go && cd ..
73
74# 5. go tool objdumpを使用して純粋な main.main アセンブリ関数を抽出
75echo "[5/6] Extracting main.main assembly sections..."
76go tool objdump -s "main\.main" main_orig > orig.asm
77go tool objdump -s "main\.main" main_asm > asm.asm
78
79# 仮想アドレス、オフセット、機械語バイトデータテキストを除去し、
80# CPUが実行する純粋な命令セット(Opcode & Operands)フィールドのみをフィルタリング
81awk '{print $4, $5, $6, $7}' orig.asm > orig_pure.asm
82awk '{print $4, $5, $6, $7}' asm.asm > asm_pure.asm
83
84# 6. 二つの機械語命令構造の diff 検証
85echo "[6/6] Verifying assembly structural integrity via diff..."
86echo "------------------------------------------------------------"
87
88if diff orig_pure.asm asm_pure.asm > /dev/null; then
89 echo "===> [成功] 二つのバイナリの main.main 機械語ロジックが100%一致します！ <==="
90 echo "コンパイラの最適化パイプラインガイドラインを完全に同期させ、同一のアセンブリを得ました。"
91else
92 echo "===> [失敗] アセンブリ命令構造に相違点が発見されました。 <==="
93 diff -u orig_pure.asm asm_pure.asm
94fi
95echo "------------------------------------------------------------"
実際にソースを実行すると、以下のような情報を得ることができます。
1[1/6] Cleaning up old artifacts...
2[2/6] Generating main.go...
3[3/6] Generating main_from_asm.go...
4[4/6] Compiling both sources inside 'test_dir'...
5[5/6] Extracting main.main assembly sections...
6[6/6] Verifying assembly structural integrity via diff...
7------------------------------------------------------------
8===> [成功] 二つのバイナリの main.main 機械語ロジックが100%一致します！ <===
9コンパイラの最適化パイプラインガイドラインを完全に同期させ、同一のアセンブリを得ました。
10------------------------------------------------------------
結論
プログラミング言語は多くの抽象化を提供しますが、その抽象化の裏側には非常に興味深く攻撃的な最適化が隠されていることが理解できたはずです。また、この点を逆手に取ることで、ソースは異なってもアセンブリは同一である「鏡像」コードを作成することもできました。低レイヤーに関心があり、Goで記述された独占的ソフトウェアに遭遇したならば、直接アセンブリを分解して分析し、ソースコードを復元することも決して不可能ではないでしょう。
次回の講義
次回は、If文とはまた異なる面白さを持つselect-case文について見ていきます。