GoSuda

Analyse van de runtimestructuur van beheerde talen en de AMD64-assembly van Go-binaries

By Lee Yunjin views ...

Wat is een managed language?

Een managed language is een taal die, in tegenstelling tot een unmanaged language, oftewel een taal die slechts uitvoert en weinig afwijkt van de logica die de programmeur heeft geschreven, GC, runtime optimizations, green threads, concurrency handling en dergelijke in de runtime uitvoert, zodat de gebruiker geen gevaarlijk laagniveaubeheer hoeft uit te voeren. Bij dit soort talen heeft men het voordeel dat men zich volledig kan concentreren op de business logic en zich kan onderdompelen in de ontwikkeling, maar anderzijds kan het gedrag van het werkelijke programma afwijken van de intuïtie van de programmeur, waardoor soms een nauwkeurige runtime tuning nodig is. Laten we eerst de Go-taal bekijken, die het meest trouw is aan de minimalistische filosofie en waarvan de assembly eerlijk is.

Binaire structuur van Go

.text.data.gopclntab, .typelink, enz.
Machinecode die wordt uitgevoerdData die wordt opgeslagenRuntimesectie van de taal

Omdat Go de invoer van de gebruiker niet één-op-één naar machinecode vertaalt, is de logica in de .text-sectie nauw verbonden met de runtimesectie van de taal. Daarnaast worden functies die de gebruiker niet zelf heeft geschreven, zoals runtime.printnl(), toegevoegd aan de assembly van de .text-sectie. Door deze automatische codeinjectie helpt Go de ontwikkelaar zich te bevrijden van handmatig beheer.

Alleen de main-functie van Go bekijken

Laten we eerst een eenvoudig voorbeeldbestand main.go schrijven en de main-functie bekijken op een AMD64-machine.

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

Vervolgens bouwen we het zo:

1go build main.go
2

Go ondersteunt de go tool voor eenvoudig laagniveau debuggen. Om alleen de assembly van de main-functie in het main-package te bekijken, voert men de volgende opdracht in via de go tool.

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
  • Met CMPQ wordt de stackguardwaarde in het goroutine control block register (R14) vergeleken met de huidige stackpointer (SP) om te controleren of er voldoende ruimte is voor het goroutine-stackframe. Als die ruimte ontoereikend is, springt de code (JBE) naar adres 0x468f95, het entrypoint voor stackuitbreiding.
  • PUSHQ BP slaat de vorige base pointer op de stack op.
  • De huidige stackpointer (SP) wordt naar het base pointer-register (BP) gekopieerd, zodat het stackreferentiepunt aan het begin van de functie wordt vastgelegd.
  • Vervolgens wordt 16 bytes stackruimte voor lokale variabelen gereserveerd (SUBQ $0x10, SP) en wordt met NOPL een pseudo-instructie ingevoegd om de CPU-cache-uitlijning te verzorgen.
  • Om de synchronisatie van de interne standaarduitvoer van de Go-runtime te waarborgen, wordt runtime.printlock(SB) aangeroepen om een lock te verkrijgen.
  • Met de LEAQ-instructie wordt het startadres van de als constante toegewezen string ("Hello World") opgeslagen in AX, het algemene register dat volgens de Go ABI-specificatie dient als eerste parameter.
  • Vervolgens wordt de waarde die de lengte van de string aangeeft in BX opgeslagen, het register voor de tweede parameter. (MOVL $0xb, BX, wat decimaal 11 is)
  • runtime.printstring(SB) wordt aangeroepen om op basis van de doorgegeven AX (dataadres) en BX (lengte) naar de console te schrijven.
  • runtime.printnl(SB) wordt aangeroepen om een regeleinde te verzorgen.
  • Omdat de uitvoer is voltooid, wordt de lock vrijgegeven via runtime.printunlock(SB).
  • De 16 bytes stackgeheugen die met ADDQ $0x10, SP was gereserveerd, worden hersteld.
  • Met POPQ BP wordt de oorspronkelijke base pointer hersteld.
  • Via RET keert de besturing terug naar het punt waar de functie werd aangeroepen.
  • Als er bij de eerste stackcontrole onvoldoende ruimte bleek te zijn, wordt runtime.morestack_noctxt.abi0(SB) op adres 0x468f95 aangeroepen om de stack dynamisch uit te breiden, zoals bij een managed language gebruikelijk is.
  • Zodra de stackuitbreiding is voltooid, keert de code terug naar het entrypoint van main.main(SB) (JMP). Zoals te zien is, is de assembly van de business logic vrij duidelijk en wordt er alleen een dunne laag runtimebeheer aan toegevoegd.

Zonder optimalisatie

Bovenstaande vorm is het resultaat van de automatische inlining en optimalisatie door de Go-compiler van de twee afzonderlijke functies. Voor onze leerdoeleinden zorgen we er echter voor dat sayHello in dit geval niet wordt geïnlined. Hiervoor compileren we de broncode met de volgende vlag.

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

Wanneer we het resultaat in de shell bekijken, vinden we duplicaten in de assembly.

 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

Wanneer de inlining wordt uitgeschakeld, worden MOVQ-instructies ingevoegd die de waarden van de parameters (AX, BX) opnieuw op stackpointer-offsets zoals 0x20(SP) opslaan, zodat deze parameters behouden blijven volgens de functieaanroepconventie. Dit bevestigt dat de compiler juist die onnodige geheugenoperaties en de overhead van functieaanroepen optimaliseert.

Volgende keer

Volgende keer behandelen we de if- en switch-statements in Go. Als er later tijd over is, zal ik ook de runtimesecties van Go analyseren.