GoSuda

Analiza structurii de execuție a limbajelor gestionate și a asamblării AMD64 a binarelor Go

By Lee Yunjin views ...

Ce este un limbaj gestionat?

Un limbaj gestionat este un limbaj care, spre deosebire de limbajele negestionate, adică limbajele care doar execută logica scrisă de programator fără a se îndepărta prea mult de aceasta, rulează în runtime funcționalități precum GC, optimizări la rulare, green threads, gestionarea concurenței etc., astfel încât utilizatorul nu trebuie să realizeze gestionări periculoase de nivel scăzut. Pentru astfel de limbaje există avantajul că dezvoltatorul se poate concentra exclusiv pe logica de business, însă, pe de altă parte, comportamentul real al programului poate diferi de intuiția programatorului, iar uneori este necesară o reglare fină a runtime-ului. Mai întâi, vom analiza limbajul Go, care dintre limbajele gestionate este cel mai fidel filozofiei minimaliste și al cărui assembly este cel mai transparent.

Structura binară a limbajului Go

.text.data.gopclntab, .typelink etc.
Cod mașină care va fi executatDate care vor fi stocateSecțiuni ale runtime-ului limbajului

Deoarece Go nu traduce codul scris de utilizator în cod mașină în raport 1:1, logica din secțiunea .text este strâns legată și de secțiunile runtime-ului limbajului. De asemenea, în assembly-ul secțiunii .text sunt adăugate funcții pe care utilizatorul nu le-a scris, precum runtime.printnl(). Prin această inserare automată de cod, Go ajută dezvoltatorul să se elibereze de gestionarea manuală.

Analiza doar a funcției main din Go

Mai întâi, să scriem un exemplu simplu, fișierul main.go, și să analizăm main pe mașină AMD64.

 1package main
 2
 3func sayHello(msg string) {
 4    println(msg)
 5}
 6
 7func main() {
 8    sayHello("Hello World")
 9}
10

Apoi compilăm astfel.

1go build main.go
2

Go oferă go tool pentru depanare simplă la nivel scăzut. Pentru a vedea doar assembly-ul funcției main din pachetul main, introducem această comandă.

1go tool objdump -s "main\.main" ./main
2

Assembly

 1TEXT main.main(SB) /home/yjlee/compare-assembly/go/main.go
 2  main.go:7             0x468f60                493b6610                CMPQ SP, 0x10(R14)
 3  main.go:7             0x468f64                762f                    JBE 0x468f95
 4  main.go:7             0x468f66                55                      PUSHQ BP
 5  main.go:7             0x468f67                4889e5                  MOVQ SP, BP
 6  main.go:7             0x468f6a                4883ec10                SUBQ $0x10, SP
 7  main.go:8             0x468f6e                90                      NOPL
 8  main.go:4             0x468f6f                e8cca3fcff              CALL runtime.printlock(SB)
 9  main.go:4             0x468f74                488d05da290100          LEAQ 0x129da(IP), AX
10  main.go:4             0x468f7b                bb0b000000              MOVL $0xb, BX
11  main.go:4             0x468f80                e83bacfcff              CALL runtime.printstring(SB)
12  main.go:4             0x468f85                e8f6a5fcff              CALL runtime.printnl(SB)
13  main.go:4             0x468f8a                e811a4fcff              CALL runtime.printunlock(SB)
14  main.go:9             0x468f8f                4883c410                ADDQ $0x10, SP
15  main.go:9             0x468f93                5d                      POPQ BP
16  main.go:9             0x468f94                c3                      RET
17  main.go:7             0x468f95                e8e6afffff              CALL runtime.morestack_noctxt.abi0(SB)
18  main.go:7             0x468f9a                ebc4                    JMP main.main(SB)
19
  • Se compară valoarea gărzii de stivă din registrul blocului de control al goroutine-ului (R14) cu pointerul curent de stivă (SP) prin CMPQ, pentru a verifica dacă spațiul de cadru de stivă al goroutine-ului curent este suficient; dacă nu este, se sare (JBE) la adresa 0x468f95, punctul de intrare pentru extinderea stivei.
  • Pentru a salva pointerul de bază anterior, PUSHQ BP îl introduce în stivă.
  • Registrul pointerului de bază (BP) primește o copie a pointerului curent de stivă (SP), fixând astfel punctul de referință al stivei la începutul funcției.
  • Apoi se alocă spațiu de stivă pentru variabile locale de 16 octeți (SUBQ $0x10, SP), iar NOPL umple cu instrucțiuni virtuale pentru alinierea cache-ului CPU.
  • Pentru sincronizarea ieșirii standard a șirurilor în runtime-ul Go, se apelează runtime.printlock(SB), care obține blocarea.
  • Cu ajutorul instrucțiunii LEAQ, adresa de început a șirului constant ("Hello World") este stocată în AX, registrul de uz general folosit ca primul parametru conform specificației Go ABI.
  • Apoi, valoarea care reprezintă lungimea șirului este stocată în BX, al doilea registru de parametri (MOVL $0xb, BX, adică 11 în zecimal).
  • Se apelează runtime.printstring(SB), care afișează în consolă pe baza informațiilor din AX (adresa datelor) și BX (lungimea).
  • Pentru a trece la rând nou, se apelează runtime.printnl(SB).
  • Deoarece afișarea s-a încheiat, blocarea este eliberată prin runtime.printunlock(SB).
  • ADDQ $0x10, SP restaurează memoria de stivă de 16 octeți alocată anterior.
  • POPQ BP restaurează pointerul de bază anterior.
  • RET returnează controlul către punctul din care a fost apelată funcția.
  • Dacă la verificarea inițială a stivei spațiul a fost insuficient, se apelează runtime.morestack_noctxt.abi0(SB) de la adresa 0x468f95, extinzând dinamic stiva prin runtime, în spiritul limbajelor gestionate.
  • După finalizarea extinderii stivei, execuția revine (JMP) la punctul de intrare al main.main(SB). După cum se observă, assembly-ul logicii de business este destul de clar și are doar o gestionare subțire a runtime-ului adăugată.

Când nu există optimizare

Forma de mai sus este rezultatul unei optimizări în care compilatorul Go a inserat automat funcțiile separate prin inlining. Totuși, pentru scopuri de studiu, în acest caz vom împiedica inlining-ul funcției sayHello. Pentru aceasta, compilăm sursa cu următorul flag.

1go build -gcflags="-l" main.go
2

Dacă afișăm rezultatul în terminal, se observă assembly duplicat.

 1yjlee@elegant:~/compare-assembly/go$ go build -gcflags="-l" main.go
 2
 3go tool objdump -s "main\.sayHello" ./main
 4TEXT main.sayHello(SB) /home/yjlee/compare-assembly/go/main.go
 5  main.go:3             0x468f60                493b6610               CMPQ SP, 0x10(R14)
 6  main.go:3             0x468f64                7636                   JBE 0x468f9c
 7  main.go:3             0x468f66                55                     PUSHQ BP
 8  main.go:3             0x468f67                4889e5                 MOVQ SP, BP
 9  main.go:3             0x468f6a                4883ec10               SUBQ $0x10, SP
10  main.go:5             0x468f6e                4889442420             MOVQ AX, 0x20(SP)
11  main.go:5             0x468f73                48895c2428             MOVQ BX, 0x28(SP)
12  main.go:4             0x468f78                e8c3a3fcff             CALL runtime.printlock(SB)
13  main.go:4             0x468f7d                488b442420             MOVQ 0x20(SP), AX
14  main.go:4             0x468f82                488b5c2428             MOVQ 0x28(SP), BX
15  main.go:4             0x468f87                e834acfcff             CALL runtime.printstring(SB)
16  main.go:4             0x468f8c                e8efa5fcff             CALL runtime.printnl(SB)
17  main.go:4             0x468f91                e80aa4fcff             CALL runtime.printunlock(SB)
18  main.go:5             0x468f96                4883c410               ADDQ $0x10, SP
19  main.go:5             0x468f9a                5d                     POPQ BP
20  main.go:5             0x468f9b                c3                     RET
21  main.go:3             0x468f9c                4889442408             MOVQ AX, 0x8(SP)
22  main.go:3             0x468fa1                48895c2410             MOVQ BX, 0x10(SP)
23  main.go:3             0x468fa6                e8d5afffff             CALL runtime.morestack_noctxt.abi0(SB)
24  main.go:3             0x468fab                488b442408             MOVQ 0x8(SP), AX
25  main.go:3             0x468fb0                488b5c2410             MOVQ 0x10(SP), BX
26  main.go:3             0x468fb5                eba9                   JMP main.sayHello(SB)
27

Când inlining-ul este dezactivat, pentru a păstra parametrii (AX, BX) conform convenției de apel a funcțiilor, se inserează operații MOVQ care reîncarcă valorile în offseturi ale pointerului de stivă, precum 0x20(SP). Prin urmare, s-a confirmat că optimizările compilatorului vizează tocmai aceste operații inutile de mutare a memoriei și supraîncărcarea apelurilor.

Următoarea oră

În următoarea oră vom discuta instrucțiunile if și switch în Go. Dacă vom avea timp în viitor, vom analiza și secțiunile runtime-ului Go.