GoSudaAnalyse van de AMD64-assemblycodegeneratie en branch-instructies voor de Go-voorwaardelijke instructie (if)
If-statements in de Go-taal
Eerst en vooral hebben we voor Go gekozen omdat Go, onder de moderne talen, de assembly het 'mooist' maakt, en soms is de efficiëntie van de syntaxis zelfs overweldigend, ook in vergelijking met klassieke talen.
Nu we in de vorige les het werkingsprincipe van een eenvoudig Go-programma hebben begrepen, gaan we Go en Assembly direct regel voor regel met elkaar vergelijken.
Broncode
Allereerst optimaliseren moderne compilers, en niet alleen Go maar ook zelfs compilers zoals GCC, automatisch vertakkingen die geen zin hebben. GCC en Clang, C-compilers, voeren ook zeer agressieve optimalisaties uit bij het industriestandaard -O2, dus het tijdperk waarin programmeurs de compiler volledig moeilijk konden vertrouwen is uiteindelijk al aan het einde van de twintigste eeuw voltooid.
Daarom heeft een voorwaarde alleen betekenis wanneer deze voor de compiler moeilijk te voorspellen is en niet eenvoudig door een andere structuur kan worden vervangen.
1package main
2
3import (
4 "os"
5 "strconv"
6)
7
8func main() {
9 // Als dit wordt opgelost met een voorspelbare en wegoptimaliseerbare waarde zoals x = 10,
10 // dan verwijdert de compiler de vertakking door te optimaliseren.
11 // Daarom gebruikt men in C voor het direct bekijken van assembly -O0 of dergelijke,
12 // of laat men de compiler een onvoorspelbare externe waarde gebruiken,
13 // maar aangezien dit gedeelte over moderne programmering gaat, gebruiken we
14 // geen methode die de binaire optimalisatie van Go uitschakelt.
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 direct als 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 de go tool wordt op een gebruiksvriendelijke manier getoond welke syntaxis overeenkomt met welke assembly-instructie.
Omdat we in dit deel de vergelijkingen en de if-vertakkingsinstructies behandelen, is het voldoende op enkele regels te letten.
CMPQ-instructie en JL-instructie
De instructie CMPQ is bedoeld om gegevenstypen van 4 bytes (4 woorden) te vergelijken, en de naam is afgeleid van CoMPareQuadword, afgekort tot CMPQ.
Op het geheugenadres 0x47a84e staat de instructie CMPQ os.Args+8(SB), $0x2.
In dit geval vergelijkt het programma het aantal ingevoerde argumenten met de hexadecimale waarde 0x2 (dat wil zeggen gewoon 2).
Vervolgens voert JL een vergelijking en sprong uit om te controleren of het aantal argumenten kleiner is dan 2 (dat wil zeggen, alleen het programma zelf als argument). De naam JL is afgeleid van Jump, Less than.
Als het aantal argumenten bij de vorige vergelijking kleiner was dan 2, springt het programma naar adres 0x47a8b0, waar een JGE staat.
Hier wordt echter het AX-register gebruikt, dus we moeten weten welke waarde in dat register is opgeslagen.
MOVQ-instructie
Hierna moeten we begrijpen hoe het CX-register daadwerkelijk wordt gebruikt om het startadres van de gegevens op te slaan en hoe de werkelijke gegevens worden opgehaald nadat het adres is gelezen.
Bij het bereik 0x47858-0x47863 wordt deze bewerking stapsgewijs uitgevoerd.
Eerst wordt het startadres van de argumentenarray met de instructie MOVQ os.Args(SB), CX in het CX-register geplaatst. Hierbij moeten we het stringtype van Go begrijpen.
De string in Go is een struct, en deze struct bestaat uit 2 gegevens van elk 8 bytes, dus in totaal 16 bytes.
| struct | 8 byte | 8 byte |
|---|---|---|
| string | mem address | string length |
Visueel ziet het er zo uit als hierboven: de eerste 8 bytes bevatten het startadres van de string, en de volgende 8 bytes bevatten de lengte van de string.
Daarom wordt het adres van de string in het AX-register opgeslagen en de lengte van de string in het BX-register.
CALL
In het vorige bericht zagen we ook bij de runtime-functies de instructie CALL.
Deze staat voor functies die in Go worden gebruikt, en betekent letterlijk dat een functie wordt aangeroepen. Vervolgens wordt met de CALL-functie de string naar een geheel getal omgezet, maar waar dit gehele getal wordt opgeslagen, is niet zichtbaar omdat het in de functie is geabstraheerd.
CMPQ-instructie en JGE-instructie
Als we terugkeren naar het eerdere adres 0x47a86c, vergelijkt de instructie het stringadres met het getal 0xa (decimaal 10)!
Dit betekent dat, aangezien het argument binnen het programma niet langer wordt gebruikt, de stringpositie is overschreven om de plaats van de gehele variabele x te creëren.
Dit is de werkelijke aard van de agressieve optimalisatie die in talen zoals Go plaatsvindt.
Vervolgens verschijnt de instructie JGE, een afkorting van Jump, Greater or Equals. Deze instructie controleert dus of de waarde groter is dan of gelijk is aan de vergelijkingswaarde.
Daarom is de vergelijkingsrichting van deze code omgekeerd ten opzichte van de syntaxis x < 10, en niet precies zoals x < 10!
Dit komt omdat het in machinecode intuïtiever is om vooraf over te slaan wanneer de voorwaarde niet overeenkomt, en dit bespaart één instructie vergeleken met het eerst uitvoeren van de vergelijking wanneer de voorwaarde overeenkomt en daarna opnieuw controleren of deze niet overeenkomt.
Deze optimalisatie is zeer klassiek, en daarom is het goed om die te kennen, omdat dit patroon ook vaak voorkomt in compilers met een relatief laag optimalisatieniveau, in tegenstelling tot het strconv.Atoi-voorbeeld hierboven.
Door dit principe toe te passen, kunnen we dus broncode krijgen die verschilt maar op assembly-niveau 100% overeenkomt.
Spiegelbeeldcode-voorbeeld
Met het onderstaande script kan een bash-script twee bronnen maken die 100% spiegelbeeldig zijn, en na het verwijderen van de metadata die telkens verandert, kan worden geverifieerd dat alleen main exact dezelfde assembly oplevert.
1#!/usr/bin/env bash
2
3# 1. Volledig initialiseren van 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. Broncode van de originele versie schrijven (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. Broncode van de spiegelbeeldversie schrijven (main_from_asm.go)
36# Operatorstructuur volledig symmetrisch synchroniseren 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 dezelfde JGE-mechanismen en blokindeling als bij main.go.
57 if x < 10 {
58 println(s1)
59 } else {
60 println(s2)
61 }
62}
63EOF
64
65# 4. Build uitvoeren in dezelfde mapstructuur en bestandsnaamomgeving
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. Pure main.main assembly-functie extraheren met 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# Virtuele adressen, offsets en machinecodebytes verwijderen en
80# alleen de zuivere instructieset (Opcode & Operands) die de CPU uitvoert filteren
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. Structurele diff-verificatie van de machinecode-instructies
85echo "[6/6] Verifying assembly structural integrity via diff..."
86echo "------------------------------------------------------------"
87
88if diff orig_pure.asm asm_pure.asm > /dev/null; then
89 echo "===> [succes] De machinecodelogica van main.main is in beide binaire bestanden 100% identiek! <==="
90 echo "Door de richtlijnen van de optimalisatiepipeline van de compiler volledig te synchroniseren, is dezelfde assembly verkregen."
91else
92 echo "===> [mislukt] Er zijn verschillen gevonden in de structuur van de assemblyinstructies. <==="
93 diff -u orig_pure.asm asm_pure.asm
94fi
95echo "------------------------------------------------------------"
Wanneer je de broncode 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===> [succes] De machinecodelogica van main.main is in beide binaire bestanden 100% identiek! <===
9Door de richtlijnen van de optimalisatiepipeline van de compiler volledig te synchroniseren, is dezelfde assembly verkregen.
10------------------------------------------------------------
Conclusie
Programmeertalen bieden veel abstracties, maar achter die abstracties schuilen zeer interessante en agressieve optimalisaties. Door hier gebruik van te maken, konden we ook spiegelbeeldcode maken die verschillend is in broncode maar identiek in assembly. Als je interesse hebt in laag-niveau programmeren en je komt een propriëtaire software in Go tegen, lijkt het niet onmogelijk om de assembly te ontleden en zo de broncode te reconstrueren.
Volgende les
In de volgende les gaan we kijken naar het select-case-statement, dat net als de if-statement veel boeiends heeft.