GoSuda

Analisi della struttura di runtime dei linguaggi gestiti e dei binari Go in assembly AMD64

By Lee Yunjin views ...

Che cos'è un linguaggio gestito?

Un linguaggio gestito è un linguaggio che, a differenza dei linguaggi non gestiti, ovvero quelli che eseguono il codice senza discostarsi molto dalla logica scritta dal programmatore, esegue nel runtime la garbage collection (GC), le ottimizzazioni a runtime, i green thread, la gestione della concorrenza e altre funzionalità simili, in modo che l'utente non debba occuparsi di gestioni a basso livello e pericolose. Questi linguaggi offrono il vantaggio di poter concentrarsi esclusivamente sulla logica di business e immergersi nello sviluppo; d'altra parte, può accadere che il comportamento effettivo del programma differisca dalle intuizioni del programmatore, rendendo talvolta necessaria una regolazione accurata del runtime. Per cominciare, esamineremo il linguaggio Go, che tra i linguaggi gestiti è quello più fedele alla filosofia minimalista e in cui l'assembly risulta più diretto.

Struttura binaria di Go

.text.data.gopclntab, .typelink ecc.
Codice macchina da eseguireDati da memorizzareSezioni del runtime del linguaggio

Poiché Go non traduce in linguaggio macchina in modo 1:1 ciò che l'utente scrive, la logica della sezione .text è strettamente correlata alle sezioni del runtime del linguaggio. Inoltre, funzioni che l'utente non ha scritto esplicitamente, come runtime.printnl(), vengono aggiunte all'assembly della sezione .text. Grazie a questa inserzione automatica di codice, Go aiuta lo sviluppatore a sollevarsi dalla gestione manuale.

Esame della sola funzione main in Go

Innanzitutto, scriviamo un semplice file sorgente di esempio main.go e osserviamo il codice a partire da main su macchina AMD64.

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

Successivamente, si compila con questo comando.

1go build main.go
2

Per il debug a basso livello, Go supporta go tool. Per visualizzare solo l'assembly della funzione main nel package main, si digita questo comando.

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
  • Viene confrontato il registro della goroutine control block (R14), che contiene il valore della stack guard, con lo stack pointer (SP) tramite CMPQ, per verificare se lo spazio del frame dello stack della goroutine corrente è sufficiente; se non lo è, si salta (JBE) all'indirizzo 0x468f95, punto di ingresso per l'espansione dello stack.
  • Il base pointer precedente viene salvato sullo stack con PUSHQ BP.
  • Il valore dello stack pointer (SP) viene copiato nel registro base pointer (BP), fissando il punto di riferimento dello stack all'inizio della funzione.
  • Successivamente viene allocato uno spazio di 16 byte per le variabili locali (SUBQ $0x10, SP), e con NOPL si inseriscono istruzioni vuote per l'allineamento alla cache della CPU.
  • Per sincronizzare l'output standard delle stringhe interno al runtime di Go, si chiama runtime.printlock(SB) per acquisire il lock.
  • Con l'istruzione LEAQ, l'indirizzo iniziale della stringa costante ("Hello World") viene caricato in AX, che secondo la convenzione ABI di Go è il primo registro di parametro.
  • Successivamente, il valore che rappresenta la lunghezza della stringa viene caricato nel secondo registro di parametro, BX (MOVL $0xb, BX, ovvero 11 in decimale).
  • Si chiama runtime.printstring(SB), che stampa in console sulla base delle informazioni passate in AX (indirizzo dei dati) e BX (lunghezza).
  • Per gestire l'a capo si chiama runtime.printnl(SB).
  • Poiché l'output è completato, il lock viene rilasciato tramite runtime.printunlock(SB).
  • Con ADDQ $0x10, SP si ripristina la memoria dello stack di 16 byte allocata in precedenza.
  • Con POPQ BP si ripristina il base pointer originale.
  • Tramite RET il controllo viene restituito al punto da cui la funzione è stata chiamata.
  • Se il controllo iniziale dello stack ha rilevato uno spazio insufficiente, si chiama runtime.morestack_noctxt.abi0(SB) all'indirizzo 0x468f95, espandendo dinamicamente lo stack tramite il runtime, come tipico dei linguaggi gestiti.
  • Al termine dell'espansione dello stack, si ritorna (JMP) al punto di ingresso di main.main(SB). Come si può vedere, l'assembly della logica di business è piuttosto chiaro e presenta soltanto una sottile gestione aggiuntiva del runtime.

Quando non ci sono ottimizzazioni

La forma precedente è il risultato di un'ottimizzazione in cui il compilatore Go ha inline automaticamente le due funzioni separate. Tuttavia, per scopi didattici, in questo caso impediremo l'inlining di sayHello. Per farlo, si compila il sorgente con il seguente flag.

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

Osservando l'output nel terminale, si trova dell'assembly duplicato.

 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

Quando l'inlining viene disabilitato, nella chiamata di funzione vengono inserite istruzioni MOVQ che ricaricano i parametri (AX, BX) nei relativi offset dello stack pointer, come 0x20(SP), per preservarli secondo la convenzione di chiamata. Ciò conferma che le operazioni di spostamento di memoria non necessarie e l'overhead di chiamata sono proprio l'oggetto dell'ottimizzazione del compilatore.

Prossima volta

La prossima volta tratteremo le istruzioni if e switch in Go. Se avremo tempo, analizzeremo anche le sezioni del runtime di Go.