GoSudaGo-voorwaardelijke instructies (if) in AMD64-assemblercodegeneratie en analyse van branch-instructies
If-statements in Go
Allereerst is de reden dat we voor Go hebben gekozen dat Go onder de moderne talen de meest 'elegante' assembly oplevert, en dat de efficiëntie van de syntaxis zelfs in vergelijking met klassieke talen soms overweldigend is.
Nu we in de vorige les het gedrag van een eenvoudig Go-programma hebben begrepen, gaan we Go en Assembly meteen regel voor regel met elkaar vergelijken.
Broncode
Allereerst optimaliseren moderne compilers, en dat geldt niet alleen voor Go maar ook voor compilers zoals GCC, automatisch vertakkingen die geen nut hebben. Ook C-compilers zoals GCC en Clang voeren bij de industriestandaard -O2 zeer agressieve optimalisaties uit, waardoor de tijd waarin programmeurs de compiler niet volledig konden vertrouwen, in feite al aan het einde van de twintigste eeuw voorbij was.
Daarom heeft het alleen zin om voorwaarden te gebruiken die voor de compiler moeilijk te voorspellen zijn en daardoor niet eenvoudig door een andere constructie vervangen kunnen worden.
1package main
2
3import (
4 "os"
5 "strconv"
6)
7
8func main() {
9 // Als we dit vervangen door iets voorspelbaars zoals x = 10, waarbij de vertakking verwijderd kan worden,
10 // dan verwijdert de compiler de vertakking door optimalisatie.
11 // Om dit daarom zelf als assembly te bekijken, zet men in C bijvoorbeeld -O0 aan, of laat men
12 // de compiler een externe waarde gebruiken die niet voorspeld kan worden,
13 // maar deze sectie behandelt modern programmeren, dus de methode waarbij de binaire optimalisatie van Go
14 // wordt uitgeschakeld, wordt niet gebruikt.
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 dit geval kan de compiler de invoer niet voorspellen, dus de vertakking wordt zonder wijzigingen naar machinecode vertaald.
Assembly
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)
Met het go tool-commando krijg je op een handige manier te zien welke broncoderegel overeenkomt met welke assembly-instructie.
Omdat we nu vergelijkingen en if-vertakkingen gaan leren, hoeven we alleen een paar regels in de gaten te houden.
CMPQ-instructie & JL-instructie
De instructie CMPQ is bedoeld om gegevens van het type 4 bytes (4 woorden) te vergelijken, en de naam is afgeleid van CoMPareQuadword, afgekort tot CMPQ.
Bij het geheugenadres 0x47a84e staat de instructie CMPQ os.Args+8(SB), $0x2.
In dit geval wordt het aantal ontvangen argumenten van het programma vergeleken met het hexadecimale getal 0x2 (dat wil zeggen gewoon 2).
Vervolgens wordt via JL na de vergelijking een sprong uitgevoerd als het aantal argumenten kleiner is dan 2 (dat wil zeggen als het programma alleen zijn eigen naam als argument heeft). Dit is de afkorting van Jump, Less than', dus JL.
Als het aantal argumenten bij de voorgaande vergelijking kleiner was dan 2, springt het programma naar adres 0x47a8b0, en daar staat een JGE.
Maar omdat deze instructie het AX-register gebruikt, moet men weten welke waarde in dat register is opgeslagen.
MOVQ-instructie
Daarna moet men begrijpen hoe het register 'CX' wordt gebruikt om het startadres van de gegevens op te slaan, en hoe de werkelijke gegevens na het lezen van dat adres worden geëxtraheerd.
In het bereik 0x47858-0x47863 zie je dat deze bewerking stap voor stap wordt uitgevoerd.
Eerst wordt het startadres van de argumentenarray met de instructie MOVQ os.Args(SB), CX in het register CX geplaatst. Hierbij moet men het stringtype van Go begrijpen.
Een string in Go is een struct, en deze struct bestaat uit twee gegevens van 8 bytes, dus in totaal 16 bytes.
| struct | 8 byte | 8 byte |
|---|---|---|
| string | geheugenadres | stringlengte |
Visueel ziet dit er zo uit als hierboven: de eerste 8 bytes bevatten het startadres van de string en de laatste 8 bytes bevatten de lengte van de string.
Daarom wordt het adres van de string in het register AX opgeslagen, en de lengte van de string in het register BX.
CALL
Ook in het vorige bericht, toen we de functies uit het runtime-pakket bekeken, stond de instructie CALL ervoor.
Deze staat voor de functies die in Go worden gebruikt, en betekent letterlijk dat een functie wordt aangeroepen, vandaar de naam CALL. Vervolgens wordt met een CALL-functie de string omgezet naar een geheel getal, en waar dit gehele getal wordt opgeslagen, is niet zichtbaar omdat dit in de functie is geabstraheerd.
CMPQ-instructie & JGE-instructie
Als we terugkeren naar het eerdere adres 0x47a86c, dan vergelijkt de instructie het adres van de string met het getal 0xa (decimaal 10)!
Dit betekent dat, omdat het programma dit argument niet meer gebruikt, de variabele x van het type geheel getal is gemaakt door de plaats van de string te overschrijven.
Dit is de werkelijke aard van de agressieve optimalisatie die in talen zoals Go wordt toegepast.
Vervolgens verschijnt de instructie JGE, een afkorting van Jump, Greater or Equals. Deze instructie vraagt dus of de waarde groter is dan of gelijk is aan de vergelijkingswaarde.
Dus de code is niet precies gelijk aan x < 10, maar x < 10 is als vergelijking gebruikt met de vergelijkingsrichting omgekeerd!
In machinecode is dit zo omdat het vooraf overslaan van de code wanneer de voorwaarde niet geldt, intuïtiever is en één instructie bespaart, vergeleken met eerst de vergelijking uitvoeren wanneer de voorwaarde wel geldt en daarna opnieuw controleren of deze niet overeenkomt.
Deze optimalisatie is zeer klassiek, en in tegenstelling tot het eerder besproken voorbeeld met strconv.Atoi is het een patroon dat ook vaak voorkomt bij compilers met een relatief lage optimalisatiegraad, dus het is nuttig om dit te weten.
Door dit toe te passen kan men dus broncode verkrijgen die verschilt, maar op assemblyniveau voor 100% overeenkomt.
Spiegelbeeldcode-voorbeeld
Met het onderstaande script kan worden geverifieerd dat het bash-script twee broncodes van 100% spiegelbeeld maakt en dat, wanneer men alleen main bekijkt en de metadata die per keer verschilt buiten beschouwing laat, exact dezelfde assembly wordt verkregen.
1#!/usr/bin/env bash
2
3# 1. Volledig opschonen van bestaande resterende bestanden en mappen
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. Schrijf de broncode van de originele versie (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. Schrijf de broncode van de spiegelbeeldversie (main_from_asm.go)
36# De operatorstructuur wordt volledig symmetrisch gesynchroniseerd, zodat de compiler het optimalisatiesjabloon (JGE) ongewijzigd gebruikt
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 // Door 10 als referentie te nemen en de structuur x < 10 te behouden, kiest de compiler
56 // exact hetzelfde JGE-mechanisme en dezelfde blokindeling als main.go.
57 switch {
58 case x < 10:
59 println(s1)
60 default:
61 println(s2)
62 }
63}
64EOF
65
66# 4. Bouw beide in dezelfde mappad- en bestandsnaamomgeving
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. Haal de pure main.main-assemblyfunctie op met 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# Verwijder de virtuele adressen, offsets en machinecode-bytetekst
81# en filter alleen de velden met de zuivere instructieset die de CPU zal uitvoeren (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. Verifieer de machinecode-instructiestructuur van beide met 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 "------------------------------------------------------------"
Wanneer je het bronprogramma daadwerkelijk uitvoert, krijg je onderstaande informatie.
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------------------------------------------------------------
Conclusie
Programmeertalen bieden veel abstractie, maar achter die abstractie schuilen zeer interessante en agressieve optimalisaties. Door dit om te keren, konden we ook spiegelbeeldcode maken die verschilt in broncode maar identieke assembly oplevert. Als je geïnteresseerd bent in laag-niveau programmeren en je komt proprietaire software in Go tegen, lijkt het niet onmogelijk om de assembly zelf te ontleden en zo de broncode te reconstrueren.
Volgende les
In de volgende les bekijken we, naast if-statements, ook de select-case-instructie, die eveneens interessant is.