GoSuda

Генерация AMD64-ассемблерного кода для условного оператора (if) в Go и анализ команд ветвления

By Lee Yunjin views ...

Оператор If в языке Go

Прежде всего, причина, по которой мы выбрали Go, состоит в том, что среди современных языков Go обладает наиболее «изящным» ассемблерным кодом, а по эффективности своего синтаксиса он порой даже превосходит классические языки.

Теперь, когда мы разобрались в принципе работы простой программы на Go на прошлом занятии, давайте сразу сравним Go и Assembly построчно.

Исходный код

Прежде всего, как и в случае с Go, современные компиляторы, включая GCC, даже автоматически оптимизируют ветвления, которые не несут никакой смысловой нагрузки. Компиляторы языка C, такие как GCC и Clang, при отраслевом стандарте -O2 выполняют весьма агрессивные оптимизации, поэтому эпоха, когда программист с трудом мог полностью доверять компилятору, фактически завершилась ещё со второй половины XX века.

Поэтому, чтобы пример вообще имел смысл, условие должно быть таким, которое компилятору трудно предсказать и заменить другой конструкцией.

 1package main
 2
 3import (
 4    "os"
 5    "strconv"
 6)
 7
 8func main() {
 9    // Если заменить это чем-то предсказуемым и допускающим удаление ветвления, например x = 10,
10    // компилятор оптимизирует код и удалит ветвление.
11    // Поэтому, чтобы увидеть это непосредственно в ассемблере, в C используют -O0 и подобные флаги,
12    // либо изначально заставляют компилятор использовать внешнее значение, которое нельзя предсказать,
13    // поскольку этот раздел посвящён современному программированию, отключать оптимизацию бинарного кода Go
14    // таким способом мы не пользуемся.
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}

В этом случае, поскольку компилятор не может предсказать входные данные, условный оператор транслируется в машинный код без изменений.

Ассемблер

 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)

Инструмент go tool любезно показывает, какой фрагмент исходного кода соответствует каким ассемблерным инструкциям.

Поскольку сегодня мы изучаем операторы сравнения и условные переходы if, достаточно обратить внимание на несколько строк.

Команды CMPQ и JL

Инструкция CMPQ предназначена для сравнения данных типа 4 байта (4 слова), и её название является сокращением от CoMPareQuadword, то есть CMPQ.

По адресу памяти 0x47a84e находится инструкция CMPQ os.Args+8(SB), $0x2. В этом случае программа сравнивает количество полученных аргументов с шестнадцатеричным 0x2 (то есть просто 2).

Затем с помощью JL выполняется переход в зависимости от результата сравнения, то есть проверяется, меньше ли количество аргументов 2 (то есть программа вызвана без аргументов, кроме собственного имени). Это сокращение от Jump, Less than' (переход, если меньше). Если по результату предыдущей операции сравнения аргументов было меньше 2, происходит переход по адресу 0x47a8b0, где находится JGE. Однако в этой инструкции используется регистр AX, поэтому необходимо понимать, что именно хранится в этом регистре.

Команда MOVQ

Далее нужно понять, как с помощью регистра 'CX' сохраняется начальный адрес данных и каким образом из прочитанного по адресу извлекаются фактические данные.

Если рассмотреть диапазон 0x47858-0x47863, видно, что эта операция выполняется поэтапно.

Сначала начальный адрес массива аргументов помещается в регистр CX с помощью инструкции MOVQ os.Args(SB), CX. При этом необходимо понимать строковый тип Go.

Тип string в Go является структурой, которая состоит из двух 8-байтовых значений, то есть занимает 16 байт.

struct8 байт8 байт
stringадрес памятидлина строки

Визуально это выглядит так, как показано выше: первые 8 байт содержат начальный адрес строки, а последние 8 байт содержат её длину.

Таким образом, адрес строки сохраняется в регистре AX, а длина строки в регистре BX.

CALL

В предыдущей статье, рассматривая функции из пакета runtime, мы также видели инструкцию CALL. Она стоит перед вызовами функций, используемых в Go, и означает, что вызывается некоторая функция; буквально это и есть CALL (вызов). Затем с помощью вызова функции CALL строка преобразуется в целое число, однако где именно сохраняется это число, скрыто абстракцией функции и не видно.

Команды CMPQ и JGE

Вернёмся к адресу 0x47a86c: инструкция сравнивает адрес строки с числом 0xa (десятичное 10)!

Это означает, что, поскольку программа больше не использует данный аргумент, компилятор перезаписал им место строки, создав место для целочисленной переменной x.

Именно в этом заключается суть агрессивной оптимизации, применяемой в Go и других языках.

Далее появляется инструкция JGE, которая является сокращением от Jump, Greater or Equals. Поэтому эта инструкция проверяет, больше ли или равно ли значение по сравнению с операндом.

Поэтому это не совсем конструкция x < 10 в её исходном виде, а x < 10: направление сравнения в инструкции перевёрнуто! Это связано с тем, что в машинном коде упреждающий переход при несовпадении условия является более наглядным и экономит одну инструкцию, по сравнению с выполнением сравнения при совпадении условия с последующей повторной проверкой на несовпадение.

Такая оптимизация очень классическая, поэтому, в отличие от примера strconv.Atoi, рассмотренного выше, она часто встречается даже в компиляторах с довольно низким уровнем оптимизации, и её полезно знать.

Поэтому, применив эту особенность, можно получить исходные коды, которые различаются по тексту, но на уровне ассемблера совпадают на 100%.

Пример зеркального кода

С помощью приведённого ниже скрипта можно проверить, что bash-скрипт создаёт два зеркальных исходника, и что при рассмотрении только main, без учёта метаданных, которые меняются от запуска к запуску, получается точно такой же ассемблерный код.

 1#!/usr/bin/env bash
 2
 3# 1. Полная очистка старых остаточных файлов и каталогов
 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. Создание исходного кода исходной версии (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. Создание исходного кода зеркальной версии (main_from_asm.go)
36# Полная симметричная синхронизация структуры операторов, чтобы компилятор использовал тот же шаблон оптимизации (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        // Если сохранить структуру x < 10, взяв 10 за основу, компилятор
56        // примет точно такой же механизм JGE и такое же размещение блоков, как в main.go.
57        switch {
58        case x < 10:
59                println(s1)
60        default:
61                println(s2)
62        }
63}
64EOF
65
66# 4. Сборка обоих вариантов в одинаковом каталоге и с одинаковым именем файла
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. Извлечение чистой ассемблерной функции main.main с помощью 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# Удаление текста виртуальных адресов, смещений и байтов машинного кода
81# и фильтрация только полей чистого набора инструкций процессора (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. Проверка структуры машинных инструкций двух файлов с помощью 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 "------------------------------------------------------------"

При запуске скрипта можно получить следующую информацию.

 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------------------------------------------------------------

Заключение

Языки программирования предоставляют множество абстракций, но за этими абстракциями скрываются весьма интересные и агрессивные оптимизации. Кроме того, используя это в обратном направлении, мы смогли создать зеркальные фрагменты кода, которые различаются по исходникам, но имеют одинаковый ассемблер. Если вас интересует низкоуровневое программирование и вы столкнётесь с проприетарным программным обеспечением на Go, то, по-видимому, разобрать ассемблерный код и восстановить исходный код тоже не является невыполнимой задачей.

Следующее занятие

На следующем занятии мы рассмотрим оператор if и ещё один интересный оператор: select-case.