L'instruction If dans le langage Go
L'instruction If dans le langage Go
Tout d'abord, notre choix de Go repose sur le fait que, parmi les langages modernes, Go possède l'assembleur le plus « élégant » et que, même comparé aux langages classiques, l'efficacité de sa syntaxe s'avère parfois écrasante.
Maintenant que nous avons appréhendé le fonctionnement d'un programme Go simple lors de la leçon précédente, comparons immédiatement Go et l'Assembly ligne par ligne.
Code source
Avant tout, comme c'est le cas avec Go, même les compilateurs modernes, y compris GCC, optimisent automatiquement les instructions de branchement qui n'ont aucune utilité. Les compilateurs C tels que GCC et Clang effectuent également des optimisations très agressives avec le niveau standard de l'industrie -O2 ; il est donc devenu acquis, depuis la fin du XXe siècle, qu'une époque où le programmeur ne peut pas faire une confiance aveugle au compilateur est bel et bien achevée.
Par conséquent, pour qu'un code ait un sens, il est nécessaire de fournir des conditions que le compilateur aura du mal à prédire et à transformer en une autre syntaxe.
1package main
2
3import (
4 "os"
5 "strconv"
6)
7
8func main() {
9 // Si l'on remplace cela par une valeur prévisible comme x = 10,
10 // permettant au compilateur de supprimer le branchement,
11 // celui-ci l'optimisera en supprimant la condition.
12 // Par conséquent, pour observer cela directement en assembleur,
13 // en langage C, on utiliserait -O0 ou on forcerait l'utilisation
14 // de valeurs externes imprévisibles par le compilateur.
15 // Comme cette section traite de la programmation moderne,
16 // nous n'utiliserons pas de méthode pour désactiver l'optimisation binaire de Go.
17 if len(os.Args) < 2 {
18 return
19 }
20 x, _ := strconv.Atoi(os.Args[1])
21
22 if x < 10 {
23 println("X is smaller than 10")
24 } else {
25 println("X is larger or same as 10")
26 }
27}
Dans ce cas, comme le compilateur ne peut pas prédire l'entrée, l'instruction de branchement est traduite telle quelle en langage machine.
Langage assembleur
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)
L'utilisation de go tool permet, avec bienveillance, d'identifier précisément quelle instruction correspond à quel code assembleur.
Puisque nous étudions ici les instructions de comparaison et de branchement if, il convient de porter une attention particulière à certaines lignes.
Instruction CMPQ & Instruction JL
L'instruction CMPQ sert à comparer des types de données de 4 octets (4 mots) ; son étymologie vient de CoMPare Quadword, d'où l'abréviation CMPQ.
En examinant l'adresse mémoire 0x47a84e, on trouve l'instruction CMPQ os.Args+8(SB), $0x2.
Dans ce cas, le programme compare le nombre d'arguments reçus avec la valeur hexadécimale 0x2 (c'est-à-dire 2).
Ensuite, si le nombre d'arguments est inférieur à 2 (c'est-à-dire si le programme n'a que lui-même comme argument), un saut est effectué via l'instruction JL. Cela signifie Jump, Less than.
Si, par rapport à la comparaison précédente, le nombre d'arguments était inférieur à 2, le programme saute à l'adresse 0x47a8b0, où se trouve une instruction JGE.
Cependant, comme cette instruction utilise le registre AX, il est nécessaire de connaître la nature de la valeur stockée dans ce registre.
Instruction MOVQ
Ensuite, il faut comprendre comment le programme utilise le registre CX pour stocker l'adresse de début des données, et comment il tente d'extraire les données réelles après avoir lu cette adresse.
En observant la plage 0x47858-0x47863, on constate que cette opération s'effectue par étapes.
Tout d'abord, l'adresse de début du tableau d'arguments est insérée dans le registre CX par l'instruction MOVQ os.Args(SB), CX. À ce stade, il est nécessaire de comprendre le type string de Go.
Le string en Go est une structure composée de 16 octets, constituée de deux données de 8 octets chacune.
| struct | 8 octets | 8 octets |
|---|---|---|
| string | adresse mem | longueur string |
Visuellement, cela donne le schéma ci-dessus : les 8 premiers octets contiennent l'adresse de début de la chaîne, et les 8 octets suivants contiennent la longueur de la chaîne.
Par conséquent, l'adresse de la chaîne est stockée dans le registre AX et sa longueur dans le registre BX.
CALL
Dans les posts précédents, en examinant les fonctions du runtime, nous avons déjà rencontré l'instruction CALL.
Celle-ci précède les fonctions utilisées par Go et, comme son nom l'indique, elle signifie appeler une fonction. Par la suite, la fonction CALL est utilisée pour convertir la chaîne en entier ; cependant, l'endroit où l'entier est stocké est abstrait par la fonction et n'apparaît pas directement.
Instruction CMPQ & Instruction JGE
En revenant à l'adresse 0x47a86c, l'instruction compare l'adresse de la chaîne avec le nombre 0xa (10 en décimal) !
Cela signifie que, comme le programme n'utilise plus cet argument, il a écrasé l'emplacement de la chaîne pour créer la variable entière x.
C'est là toute la réalité de l'optimisation agressive pratiquée par des langages comme Go.
Ensuite, l'instruction JGE apparaît ; il s'agit de l'abréviation de Jump, Greater or Equals. Cette instruction vérifie donc si la valeur est supérieure ou égale à l'objet de la comparaison.
Ainsi, ce n'est pas exactement la syntaxe x < 10 qui est utilisée, mais le sens de la comparaison est inversé par rapport à x < 10 !
Cela s'explique par le fait qu'en langage machine, sauter préventivement lorsque la condition n'est pas remplie est plus intuitif et permet d'économiser une instruction par rapport au fait d'effectuer la comparaison une fois, puis de vérifier à nouveau si la condition n'est pas remplie.
Cette optimisation est très classique ; contrairement à l'exemple strconv.Atoi vu plus haut, c'est un motif qui apparaît fréquemment même dans des compilateurs au niveau d'optimisation assez bas, il est donc utile de le connaître.
Par conséquent, en appliquant ces principes, il est possible d'obtenir un code source qui, bien que différent, produit un assembleur identique.
Exemple de code miroir
En utilisant le script ci-dessous, vous pouvez vérifier que le script Bash génère deux sources "miroirs" à 100 % qui, une fois les métadonnées variables écartées, produisent un assembleur rigoureusement identique pour la fonction main.
1#!/usr/bin/env bash
2
3# 1. Initialisation complète des anciens fichiers et répertoires résiduels
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. Écriture du code source de la version originale (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. Écriture du code source de la version miroir (main_from_asm.go)
36# Synchronisation symétrique parfaite de la structure des opérateurs pour que le compilateur utilise le même template d'optimisation (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 // En prenant 10 comme base et en conservant la structure x < 10, le compilateur
56 // adopte exactement le même mécanisme JGE et la même disposition des blocs que dans main.go.
57 if x < 10 {
58 println(s1)
59 } else {
60 println(s2)
61 }
62}
63EOF
64
65# 4. Compilation dans un environnement de chemin de répertoire et de nom de fichier identique
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. Extraction de la fonction assembleur pure main.main en utilisant 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# Suppression des adresses virtuelles, des offsets et des données binaires machine
80# pour ne filtrer que le jeu d'instructions pur (Opcode & Operands) que le CPU exécutera
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. Vérification diff de la structure des deux instructions machine
85echo "[6/6] Verifying assembly structural integrity via diff..."
86echo "------------------------------------------------------------"
87
88if diff orig_pure.asm asm_pure.asm > /dev/null; then
89 echo "===> [Succès] La logique machine de main.main des deux binaires est identique à 100 % ! <==="
90 echo "Grâce à une synchronisation parfaite des directives du pipeline d'optimisation du compilateur, nous avons obtenu le même assembleur."
91else
92 echo "===> [Échec] Des différences ont été détectées dans la structure des instructions assembleur. <==="
93 diff -u orig_pure.asm asm_pure.asm
94fi
95echo "------------------------------------------------------------"
En exécutant réellement les sources, vous pouvez obtenir les informations suivantes :
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===> [Succès] La logique machine de main.main des deux binaires est identique à 100 % ! <===
9Grâce à une synchronisation parfaite des directives du pipeline d'optimisation du compilateur, nous avons obtenu le même assembleur.
10------------------------------------------------------------
Conclusion
Bien que les langages de programmation offrent de nombreuses abstractions, nous avons pu constater que des optimisations très intéressantes et agressives se cachent derrière ces dernières. En outre, nous avons pu exploiter ces aspects pour créer un code "miroir" avec des sources différentes, mais un assembleur identique. Si vous vous intéressez au bas niveau et que vous rencontrez un logiciel propriétaire écrit en Go, il ne semble pas impossible de récupérer le code source en désassemblant et en analysant directement l'assembleur.
Leçon suivante
La prochaine fois, nous aborderons l'instruction select-case, qui présente un intérêt tout aussi captivant que l'instruction If.