GoSudaGo feltételes utasítások (if) AMD64 assembly kódgenerálása és az elágazó utasítások elemzése
Az If-utasítás a Go nyelvben
Először is, azért választottuk a Go-t, mert a modern nyelvek közül a Go assembly kódja a legszépebb, és szintaxisának hatékonysága a klasszikus nyelvekhez képest is néha egyenesen lenyűgöző.
Most, hogy az előző előadásban megértettük egy egyszerű Go program működési módját, hasonlítsuk össze közvetlenül a Go-t és az Assembly-t soronként.
Forráskód
Először is, a Go-ban is, sőt még a GCC-t is beleértve a modern fordítók automatikusan optimalizálják azokat az elágazásokat, amelyeknek nincs értelme. A GCC és a Clang, vagyis a C nyelvű fordítók is nagyon agresszív optimalizálást végeznek az iparági szabványnak számító -O2 kapcsolóval, így az a korszak, amikor a programozó nem bízhatott teljesen a fordítóban, a 20. század második felében véglegesen lezárult.
Ezért a fordító szempontjából olyan feltételt kell megadni, amelyet nehéz előre megjósolni és más szerkezetre cserélni, hogy az legalább értelmet nyerjen.
1package main
2
3import (
4 "os"
5 "strconv"
6)
7
8func main() {
9 // Ha ezt olyan értékkel helyettesítjük, mint az x = 10, amely előre megjósolható és amelynek elágazása eltávolítható,
10 // a fordító optimalizálja, és eltávolítja az elágazást.
11 // Ezért ha ezt assemblyben szeretnénk megfigyelni, C nyelven a -O0 vagy hasonló kapcsolót használjuk,
12 // vagy a fordító számára előre nem jósolható külső értéket adunk meg,
13 // de mivel ez a rész a modern programozással foglalkozik, a Go bináris optimalizálásának
14 // kikapcsolását nem alkalmazzuk.
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}
Ebben az esetben, mivel a fordító nem tudja megjósolni a bemenetet, az elágazási utasítás változatlanul gépi kódra fordítódik.
Assembly nyelv
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)
A go tool segítségével kedvesen megmutatja, melyik szerkezet melyik assembly kódnak felel meg.
Most, hogy az elágazásokat vizsgáljuk, csak néhány sorra kell figyelnünk.
CMPQ utasítás és JL utasítás
A CMPQ utasítás 4 bájtos (4 szavas) adattípusok összehasonlítására szolgál, neve a CoMPareQuadword kifejezésből származik, amelyet CMPQ-ra rövidítettek.
A 0x47a84e memóriacímen a CMPQ os.Args+8(SB), $0x2 utasítás található.
Ebben az esetben a program által kapott argumentumok számát hasonlítja össze a 16-os számrendszerbeli 0x2-vel (vagyis egyszerűen 2-vel).
Ezt követően a JL utasítással, ha az argumentumok száma kisebb 2-nél (vagyis ha a program csak saját magát kapja argumentumként), ugrás történik az összehasonlítás után. Ez a Jump, Less than rövidítése, innen a JL név.
Ha az előző összehasonlítás alapján az argumentumok száma kisebb volt 2-nél, a program a 0x47a8b0 címre ugrik, ahol a JGE utasítás található.
Azonban ebben a részben az AX regisztert használjuk, ezért ismernünk kell a regiszterben tárolt érték jelentését.
MOVQ utasítás
Ezt követően a CX regiszter segítségével tároljuk az adat kezdőcímét, és meg kell értenünk, hogyan vonja ki a program a tényleges adatot a cím beolvasása után.
A 0x47858-0x47863 tartományt vizsgálva ez a művelet lépésenként történik.
Először a MOVQ os.Args(SB), CX utasítással helyezzük az argumentumtömb kezdőcímét a CX regiszterbe. Ehhez értenünk kell a Go string típusát.
A Go string egy struktúra, amely két darab 8 bájtos adatból, összesen 16 bájtból áll.
| struct | 8 byte | 8 byte |
|---|---|---|
| string | mem address | string length |
Vizuálisan a fentihez hasonlóan ábrázolható: az első 8 bájt a string kezdőcímét, a második 8 bájt pedig a string hosszát tartalmazza.
Ezért a string címét az AX regiszterbe, a string hosszát a BX regiszterbe tároljuk.
CALL
A korábbi bejegyzésben is, amikor a runtime függvényeket vizsgáltuk, a CALL utasítás állt előttük.
Ez a Go függvényei előtt szerepel, és azt jelenti, hogy egy függvényt meghív, szó szerint CALL. Ezt követően a CALL segítségével alakítjuk a stringet egész számmá, de az, hogy az egész számot hova tárolja, a függvénybe absztrahálva nem látható.
CMPQ utasítás és JGE utasítás
Visszatérve a korábban említett 0x47a86c címhez, az utasítás a string címét és a 0xa számot (tízes számrendszerben 10) hasonlítja össze!
Ez azt jelenti, hogy a programban a továbbiakban nem használjuk fel az adott argumentumot, ezért a string helyére írva létrehozta az egész típusú x változó helyét.
Ez a Go és más nyelvek esetében végrehajtott agresszív optimalizálás lényege.
Ezután megjelenik a JGE utasítás, amely a Jump, Greater or Equals rövidítése. Ez az utasítás tehát azt vizsgálja, hogy az összehasonlított érték nagyobb-e vagy egyenlő-e.
Ezért a x < 10 kifejezés nem pontosan ebben a formában szerepel, hanem az összehasonlítás iránya megfordult!
Ez a gépi kódban azért előnyös, mert ha a feltétel nem teljesül, akkor az előre történő átugrás intuitívabb, és egy utasítást megtakarít, mintha a feltétel teljesülésekor egyszer elvégezné az összehasonlítást, majd újra ellenőrizné, hogy nem teljesül-e.
Ez az optimalizáció nagyon klasszikus, ezért a fent látott strconv.Atoi példától eltérően az alacsony szintű optimalizációt végző fordítókban is gyakran megjelenik, így érdemes ismerni.
Ennek a mintának az alkalmazásával a források eltérhetnek, de assembly szinten 100%-ban megegyező forrásokat kaphatunk.
Tükörkép kód példa
Az alábbi szkript segítségével a bash szkript 100%-ban tükörképes két forrást hoz létre, majd a változó metaadatok kivételével csak a main függvényt vizsgálva pontosan ugyanazt az assembly kódot kapjuk, amelyet ellenőrizni lehet.
1#!/usr/bin/env bash
2
3# 1. A korábbi maradék fájlok és könyvtárak teljes törlése
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. Az eredeti verzió forráskódjának írása (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. A tükörkép verzió forráskódjának írása (main_from_asm.go)
36# A fordító optimalizálási sablonját (JGE) pontosan ugyanúgy használja, mivel az operátor szerkezete teljesen szimmetrikusan szinkronizálva van
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 // Ha a 10-et alapul véve megtartjuk az x < 10 szerkezetet, a fordító pontosan ugyanazt a JGE mechanizmust és blokkelrendezést alkalmazza, mint a main.go esetében.
56 switch {
57 case x < 10:
58 println(s1)
59 default:
60 println(s2)
61 }
62}
63EOF
64
65# 4. Mindkét build végrehajtása ugyanabban a könyvtárelérési útban és fájlnév környezetben
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 ..
69rm test_dir/main.go
70
71cp main_from_asm.go test_dir/main.go
72cd test_dir && go build -o ../main_asm main.go && cd ..
73
74# 5. A main.main tiszta assembly függvényének kinyerése go tool objdump segítségével
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# A virtuális címek, eltolások és a gépi kódbájt adatok szövegének eltávolítása,
80# csak a CPU által végrehajtandó tiszta utasításkészlet (Opcode és Operands) mezőinek szűrése
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. A két gépi kódú utasításstruktúra diff-ellenőrzése
85echo "[6/6] Verifying assembly structural integrity via diff..."
86echo "------------------------------------------------------------"
87if diff orig_pure.asm asm_pure.asm > /dev/null; then
88 echo "===> [성공] 두 바이너리의 main.main 기계어 로직이 100% 일치합니다! <==="
89 echo "컴파일러의 최적화 파이프라인 가이드라인을 완벽하게 동기화하여 동일한 어셈블리를 얻었습니다."
90else
91 echo "===> [실패] 어셈블리 명령어 구조에 차이점이 발견되었습니다. <==="
92 diff -u orig_pure.asm asm_pure.asm
93fi
94echo "------------------------------------------------------------"
A szkriptet futtatva a következő információkat kapjuk.
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------------------------------------------------------------
결론
A programozási nyelvek sok absztrakciót kínálnak, de az absztrakció mögött nagyon érdekes és agresszív optimalizációk húzódnak meg. Ezt a jelenséget kihasználva olyan tükörképes kódot is létre tudtunk hozni, amelynek forrása eltérő, assemblyje azonban megegyezik. Ha érdekel az alacsony szint, és egy Go nyelven írt zárt forráskódú szoftverrel találkozunk, az assembly szétszedésével és elemzésével a forrás visszaállítása sem tűnik lehetetlen feladatnak.
Következő előadás
A következő alkalommal az If-utasításról és egy másik érdekes témáról, a select-case utasításról lesz szó.