Analyse der AMD64-Assemblercodegenerierung und Verzweigungsbefehle für Go-Bedingungsanweisungen (if)

Die If-Anweisung in Go
Zunächst haben wir uns für Go entschieden, weil Go unter den modernen Sprachen den wohl „schönsten" Assemblercode erzeugt und die Effizienz seiner Syntax im Vergleich zu klassischen Sprachen mitunter sogar überwältigend ist.
Nachdem wir in der vorherigen Vorlesung die Funktionsweise eines einfachen Go-Programms verstanden haben, wollen wir nun Go und Assembly Zeile für Zeile miteinander vergleichen.
Quellcode
Zunächst gilt: Nicht nur Go, sondern sogar moderne Compiler einschließlich GCC optimieren Verzweigungen, die keinen Zweck erfüllen, automatisch weg. GCC und Clang, also C-Compiler, nehmen auf der in der Branche üblichen Stufe -O2 sehr aggressive Optimierungen vor. Die Zeit, in der Programmierer dem Compiler nur schwer uneingeschränkt vertrauen konnten, ist somit spätestens seit dem Ende des 20. Jahrhunderts endgültig vorbei.
Daher muss man dem Compiler Bedingungen vorgeben, die er nicht ohne Weiteres vorhersagen und durch eine andere Konstruktion ersetzen kann, damit das Beispiel überhaupt eine Bedeutung hat.
1package main
2
3import (
4 "os"
5 "strconv"
6)
7
8func main() {
9 // Wenn man hier etwas wie x = 10 einsetzt, also einen vorhersehbaren Wert, dessen Verzweigung entfernt werden kann,
10 // optimiert der Compiler und entfernt die Verzweigung.
11 // Um dies in Assembly zu betrachten, würde man in C etwa -O0 verwenden oder dem Compiler
12 // von vornherein einen für ihn nicht vorhersagbaren externen Wert übergeben.
13 // Da dieser Abschnitt moderne Programmierung behandelt, wird das Abschalten
14 // der binären Optimierung in Go nicht verwendet.
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}
In diesem Fall kann der Compiler die Eingabe nicht vorhersagen, weshalb die Verzweigung unverändert in Maschinencode übersetzt wird.
Assembly-Sprache
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)
Der go tool zeigt dankenswerterweise an, welche Anweisung des Quellcodes welchem Assemblerbefehl entspricht, und zwar Zeile für Zeile.
Da wir in dieser Lektion If-Verzweigungen und Vergleichsanweisungen behandeln, genügt es, auf einige wenige Zeilen zu achten.
CMPQ-Befehl & JL-Befehl
Der Befehl CMPQ dient dem Vergleich von Operanden des Datentyps mit 4 Byte (4 Wort). Sein Ursprung liegt in CoMPareQuadword, woraus er zu CMPQ verkürzt wurde.
Betrachtet man die Speicheradresse 0x47a84e, so findet sich dort die Anweisung CMPQ os.Args+8(SB), $0x2.
In diesem Fall vergleicht das Programm die Anzahl der übergebenen Argumente mit der hexadezimalen Zahl 0x2 (also schlicht 2).
Anschließend führt JL abhängig vom Ergebnis des Vergleichs einen Sprung aus, und zwar dann, wenn die Anzahl der Argumente kleiner als 2 ist (also wenn nur das Programm selbst als Argument vorliegt). JL ist die Abkürzung für Jump, Less than.
War die Anzahl der Argumente beim vorherigen Vergleich kleiner als 2, so springt das Programm zur Adresse 0x47a8b0, wo sich ein JGE befindet.
Da in dieser Anweisung jedoch das Register AX verwendet wird, muss man wissen, welcher Wert in diesem Register gespeichert ist.
MOVQ-Befehl
Als Nächstes muss man verstehen, wie das Register CX tatsächlich genutzt wird, um die Startadresse der Daten zu speichern, und wie anschließend die eigentlichen Daten aus der gelesenen Adresse extrahiert werden.
Der Bereich 0x47858-0x47863 zeigt diesen Vorgang schrittweise.
Zunächst wird die Startadresse des Argument-Arrays mit dem Befehl MOVQ os.Args(SB), CX in das Register CX geladen. Dabei muss man den String-Typ von Go verstehen.
Der string in Go ist eine Struktur, die aus zwei Daten mit jeweils 8 Byte besteht und somit insgesamt 16 Byte umfasst.
| struct | 8 Byte | 8 Byte |
|---|---|---|
| string | Speicheradresse | Stringlänge |
Visuell lässt sich dies wie oben darstellen: Die vorderen 8 Byte enthalten die Startadresse des Strings, die hinteren 8 Byte die Länge des Strings.
Daher wird die Adresse des Strings im Register AX und die Länge des Strings im Register BX gespeichert.
CALL
Auch im vorherigen Beitrag stand bei der Betrachtung der Funktionen aus dem runtime-Paket der Befehl CALL.
Dieser steht vor Funktionen, die in Go verwendet werden, und bedeutet wörtlich, dass eine Funktion aufgerufen wird. Anschließend wird mit CALL eine Funktion ausgeführt, die den String in eine Ganzzahl umwandelt. Wohin diese Ganzzahl gespeichert wird, bleibt verborgen, da dies durch die Funktion abstrahiert ist und nicht sichtbar wird.
CMPQ-Befehl & JGE-Befehl
Kehren wir nun zur bereits genannten Adresse 0x47a86c zurück: Dort wird die Adresse des Strings mit der Zahl 0xa (dezimal 10) verglichen!
Das bedeutet, dass das Programm das Argument nicht mehr verwendet und daher den String-Platz überschrieben hat, um Raum für die Ganzzahlvariable x zu schaffen.
Dies ist das eigentliche Wesen der aggressiven Optimierung, wie sie unter anderem in Go vorgenommen wird.
Danach tritt der Befehl JGE auf, die Abkürzung für Jump, Greater or Equals. Diese Anweisung prüft daher, ob der Wert im Vergleich zum Vergleichsoperanden größer oder gleich ist.
Somit entspricht der Ausdruck nicht unmittelbar x < 10, sondern die Vergleichsrichtung ist umgekehrt!
Auf Maschinenebene ist dies intuitiver und spart einen Befehl, denn wenn die Bedingung nicht zutrifft, wird vorab übersprungen. Andernfalls müsste der Vergleich im Fall des Zutreffens einmal ausgeführt und danach erneut geprüft werden, ob die Bedingung nicht zutrifft.
Diese Optimierung ist sehr klassisch. Anders als das oben betrachtete Beispiel strconv.Atoi taucht sie daher auch bei Compilern mit eher geringem Optimierungsniveau häufig auf, weshalb es sich lohnt, sie zu kennen.
Durch Anwendung dieser Erkenntnisse lässt sich somit ein Quellcode erzeugen, der sich vom Original unterscheidet, auf Assembly-Ebene jedoch zu 100 % übereinstimmt.
Spiegelbildliches Codebeispiel
Mit dem folgenden Skript erzeugt das Bash-Skript zwei Quellen, die 100 % spiegelbildlich zueinander sind. Anschließend lässt sich nach Entfernen der jeweils variierenden Metadaten überprüfen, dass bei alleiniger Betrachtung von main exakt identischer Assemblercode entsteht.
1#!/usr/bin/env bash
2
3# 1. Vollständige Bereinigung vorhandener Restdateien und Verzeichnisse
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. Erstellen des Quellcodes der Originalversion (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. Erstellen des Quellcodes der spiegelbildlichen Version (main_from_asm.go)
36# Die Operatorstruktur wird vollständig symmetrisch synchronisiert, damit der Compiler das Optimierungsmuster (JGE) unverändert übernimmt
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 switch {
58 case x < 10:
59 println(s1)
60 default:
61 println(s2)
62 }
63}
64EOF
65
66# 4. Separates Bauen in derselben Verzeichnis- und Dateinamenumgebung
67echo "[4/6] Compiling both sources inside 'test_dir'..."
68cp main.go test_dir/main.go
69cd test_dir && go build -o ../main_orig main.go && cd ..
70rm test_dir/main.go
71
72cp main_from_asm.go test_dir/main.go
73cd test_dir && go build -o ../main_asm main.go && cd ..
74
75# 5. Extrahieren der reinen Assembly-Funktion main.main mithilfe von go tool objdump
76echo "[5/6] Extracting main.main assembly sections..."
77go tool objdump -s "main\.main" main_orig > orig.asm
78go tool objdump -s "main\.main" main_asm > asm.asm
79
80# Entfernen der virtuellen Adressen, Offsets und Maschinencode-Bytedaten
81# und Filtern ausschließlich der Felder des vom CPU auszuführenden reinen Befehlssatzes (Opcode & Operands)
82awk '{print $4, $5, $6, $7}' orig.asm > orig_pure.asm
83awk '{print $4, $5, $6, $7}' asm.asm > asm_pure.asm
84
85# 6. Überprüfung der Befehlsstruktur beider Maschinencodes per diff
86echo "[6/6] Verifying assembly structural integrity via diff..."
87echo "------------------------------------------------------------"
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 "------------------------------------------------------------"
Bei tatsächlicher Ausführung des Skripts erhält man folgende Informationen.
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------------------------------------------------------------
Fazit
Programmiersprachen bieten zahlreiche Abstraktionen, doch hinter diesen Abstraktionen verbergen sich sehr interessante und aggressive Optimierungen. Außerdem ließ sich dieser Umstand umkehren, sodass spiegelbildlicher Code entstehen konnte, dessen Quellcode sich unterscheidet, dessen Assembly jedoch identisch ist. Wer sich für die Low-Level-Ebene interessiert und auf proprietäre Software in Go stößt, für den erscheint es nicht unmöglich, den Assemblercode zu zerlegen und daraus den Quellcode zu rekonstruieren.
Nächste Vorlesung
In der nächsten Stunde werden wir neben der If-Anweisung auch die ebenfalls interessante select-case-Anweisung betrachten.