GoSudaAnaliza generowania kodu asemblerowego AMD64 dla instrukcji warunkowej if w języku Go oraz instrukcji rozgałęzień
Instrukcja If w języku Go
Przede wszystkim, powodem, dla którego wybraliśmy Go, jest to, że spośród nowoczesnych języków Go ma najbardziej "piękny" assembler, a efektywność jego składni bywa wręcz przytłaczająca nawet w porównaniu z językami klasycznymi.
Skoro w poprzednim wykładzie zrozumieliśmy sposób działania prostego programu w Go, przejdźmy od razu do porównania Go i Assembly wiersz po wierszu.
Kod źródłowy
Przede wszystkim, nie tylko w Go, ale nawet nowoczesne kompilatory, w tym GCC, automatycznie optymalizują instrukcje rozgałęzień, które nie mają znaczenia. Kompilatory języka C, takie jak GCC i Clang, stosują bardzo agresywne optymalizacje już na poziomie -O2, będącym standardem branżowym, zatem era, w której programista nie mógł w pełni ufać kompilatorowi, dobiegła końca już pod koniec XX wieku.
Dlatego też, z punktu widzenia kompilatora, warunek musi być taki, który trudno przewidzieć i zastąpić inną konstrukcją, aby miał on przynajmniej sens.
1package main
2
3import (
4 "os"
5 "strconv"
6)
7
8func main() {
9 // Jeśli zastąpimy to czymś przewidywalnym i możliwym do usunięcia, na przykład x = 10,
10 // kompilator zoptymalizuje kod i usunie rozgałęzienie.
11 // Dlatego, aby samodzielnie obejrzeć taki kod w assemblerze, w języku C stosuje się -O0 itp.
12 // lub sprawia się, że kompilator używa zewnętrznej wartości, której nie może przewidzieć.
13 // Ponieważ ten rozdział dotyczy nowoczesnego programowania, nie stosujemy
14 // w Go metody wyłączania optymalizacji binarnej.
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}
W tym przypadku, ponieważ kompilator nie może przewidzieć danych wejściowych, instrukcja rozgałęzienia zostaje przetłumaczona na kod maszynowy bez zmian.
Assembler
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)
Narzędzie go tool w sposób przystępny pokazuje, który fragment kodu źródłowego odpowiada której instrukcji assemblera.
Ponieważ w tej lekcji uczymy się o porównaniach i instrukcji rozgałęzienia if, wystarczy zwrócić uwagę na kilka wierszy.
CMPQ i JL
Instrukcja CMPQ służy do porównywania danych typu 4 bajtów (4 słowa), a jej nazwa pochodzi od CoMPareQuadword, skrócone do CMPQ.
Pod adresem pamięci 0x47a84e znajduje się instrukcja CMPQ os.Args+8(SB), $0x2.
W tym przypadku program porównuje liczbę otrzymanych argumentów z szesnastkową wartością 0x2 (czyli po prostu 2).
Następnie, aby sprawdzić, czy liczba argumentów jest mniejsza od 2 (czyli czy program otrzymał tylko samego siebie jako argument), wykonywany jest skok za pomocą JL. Oznacza on Jump, Less than, czyli skok, jeśli mniejsze, stąd nazwa JL.
Jeśli wynik porównania wskazuje, że argumentów było mniej niż 2, program skacze pod adres 0x47a8b0, gdzie znajduje się JGE.
Jednak w tej części używany jest rejestr AX, dlatego trzeba poznać, co jest zapisane w tym rejestrze.
MOVQ
Następnie należy zrozumieć, jak za pomocą rejestru 'CX' zapisywany jest adres początkowy danych, oraz jak wyodrębniane są rzeczywiste dane po odczytaniu tego adresu.
Zakres 0x47858-0x47863 pokazuje te operacje wykonywane krok po kroku.
Najpierw adres początkowy tablicy argumentów zostaje wstawiony do rejestru CX za pomocą instrukcji MOVQ os.Args(SB), CX. W tym miejscu trzeba zrozumieć typ string w Go.
string w Go jest strukturą, która składa się z dwóch 8-bajtowych wartości, co daje 16 bajtów.
| struct | 8 byte | 8 byte |
|---|---|---|
| string | mem address | string length |
Wizualnie wygląda to tak jak powyżej: pierwsze 8 bajtów przechowuje adres początkowy łańcucha, a kolejne 8 bajtów jego długość.
Dlatego adres łańcucha zapisywany jest w rejestrze AX, a jego długość w rejestrze BX.
CALL
We wcześniejszym poście, przy analizie funkcji z pakietu runtime, również pojawiała się instrukcja CALL.
Jest ona dołączana do funkcji używanych w Go i oznacza wywołanie danej funkcji, dlatego nazywa się ją dosłownie CALL. Następnie funkcja CALL służy do przekształcenia łańcucha w liczbę całkowitą, przy czym to, gdzie ta liczba jest zapisywana, nie jest widoczne, ponieważ zostało ukryte w abstrakcji funkcji.
CMPQ i JGE
Wracając do adresu 0x47a86c, instrukcja porównuje adres łańcucha z liczbą 0xa (w systemie dziesiętnym 10)!
Oznacza to, że ponieważ program nie korzysta już z tego argumentu, nadpisano nim położenie łańcucha, tworząc miejsce na zmienną całkowitą x.
Właśnie to jest istotą agresywnej optymalizacji, jaką wykonuje m.in. język Go.
Następnie pojawia się instrukcja JGE, której skrót oznacza Jump, Greater or Equals, czyli skok, jeśli większe lub równe. Ta instrukcja sprawdza więc, czy wartość jest większa lub równa wartości porównawczej.
Zatem zamiast dokładnie x < 10, kierunek porównania w kodzie jest odwrócony!
Wynika to z tego, że na poziomie kodu maszynowego bardziej intuicyjne jest wcześniejsze pominięcie bloku, gdy warunek nie jest spełniony, niż wykonanie porównania w przypadku spełnienia warunku i ponowne sprawdzenie, czy warunek nie jest spełniony, a dzięki temu oszczędza się jedną instrukcję.
Ta optymalizacja jest bardzo klasyczna, dlatego pojawia się często nawet w kompilatorach o znacznie niższym poziomie optymalizacji niż ten, w którym działa przykład z strconv.Atoi, więc warto ją znać.
Stosując tę zasadę, można uzyskać źródła różniące się składnią, lecz dające na poziomie assemblera w 100% identyczny wynik.
Przykład kodu lustrzanego
Korzystając z poniższego skryptu, skrypt bashowy generuje dwa źródła będące w 100% lustrzanym odbiciem siebie, a następnie pozwala zweryfikować, że po pominięciu metadanych, które się zmieniają, dla samego main otrzymuje się dokładnie ten sam assembler.
1#!/usr/bin/env bash
2
3# 1. Całkowite wyczyszczenie pozostałych plików i katalogów
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. Zapisanie kodu źródłowego wersji oryginalnej (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. Zapisanie kodu źródłowego wersji lustrzanej (main_from_asm.go)
36# Strukturę operatorów w pełni symetryzuje się tak, aby kompilator użył szablonu optymalizacji (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 // Jeśli za punkt odniesienia przyjmie się 10 i zachowa strukturę x < 10, kompilator
56 // zastosuje dokładnie ten sam mechanizm JGE oraz układ bloków co w main.go.
57 if x < 10 {
58 println(s1)
59 } else {
60 println(s2)
61 }
62}
63EOF
64
65# 4. Kompilacja obu źródeł w tej samej ścieżce katalogu i pod tą samą nazwą pliku
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. Wyodrębnienie czystych sekcji assemblera funkcji main.main za pomocą go tool objdump
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# Usunięcie wirtualnych adresów, przesunięć oraz tekstu bajtów maszynowych
80# i pozostawienie wyłącznie pól instrukcji wykonywanych przez procesor (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. Weryfikacja struktury instrukcji maszynowych za pomocą 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 "------------------------------------------------------------"
Po uruchomieniu skryptu otrzymuje się następujące informacje.
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------------------------------------------------------------
Wnioski
Języki programowania oferują wiele abstrakcji, lecz za nimi kryją się bardzo interesujące i agresywne optymalizacje. Wykorzystując tę właściwość, udało się także stworzyć lustrzane fragmenty kodu, które różnią się źródłem, lecz mają identyczny assembler. Jeśli interesuje Cię programowanie niskopoziomowe i natrafisz na zamknięte oprogramowanie napisane w Go, odtworzenie kodu źródłowego poprzez analizę i dekompilację assemblera nie wydaje się zadaniem niemożliwym.
Następny wykład
Na następnych zajęciach zajmiemy się instrukcją If oraz inną ciekawą konstrukcją, czyli select-case.