GoSudaAnalyse av runtime-strukturen i administrerte språk og AMD64-assembly i Go-binærfiler
Hva er et administrert språk?
Et administrert språk er et språk som, i motsetning til et uadministrert språk, altså et språk som i hovedsak utfører logikken programmereren har skrevet uten å avvike vesentlig fra den, utfører GC, kjøretidsoptimalisering, grønne tråder, samtidighetshåndtering og lignende i kjøretiden, slik at brukeren ikke trenger å utføre farlig lavnivåhåndtering selv. For slike språk er fordelen at man kan konsentrere seg om forretningslogikken og fordype seg i utviklingen, men ulempen er at programmererens intuisjon og det faktiske programmets oppførsel kan avvike, slik at presis finjustering av kjøretiden til tider er nødvendig. Først skal vi se på Go, som av de administrerte språkene er det som best holder seg til en minimalistisk filosofi og hvor assemblerkoden er ærlig.
Binærstrukturen til Go-språket
| .text | .data | .gopclntab, .typelink osv. |
|---|---|---|
| Maskinkode som skal kjøres | Data som skal lagres | Språkets kjøretidsseksjoner |
Go oversetter ikke brukerens kode 1:1 til maskinkode, og derfor er logikken i .text-seksjonen nøye knyttet til kjøretidsseksjonene for språket. Dessuten legges funksjoner som runtime.printnl() , som brukeren ikke har skrevet selv, inn i assemblerkoden i .text-seksjonen. Gjennom denne automatiske kodeinnsettingen hjelper Go utvikleren å slippe manuell håndtering.
Kun main-funksjonen i Go
Først lager vi et enkelt eksempelkildekodefilen main.go og ser på main fra og med AMD64-maskinen.
1package main
2
3func sayHello(msg string) {
4 println(msg)
5}
6
7func main() {
8 sayHello("Hello World")
9}
10
Deretter bygger vi slik:
1go build main.go
2
For enkel lavnivåfeilsøking støtter Go verktøyet go tool. For å se bare så mye assemblerkode som hovedfunksjonen i main-pakken utgjør, skriver vi inn denne kommandoen.
1go tool objdump -s "main\.main" ./main
2
Assembler
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
- Sjekker om den nåværende goroutinens stakkrammeplass er tilstrekkelig ved å sammenligne stakkvakten i goroutinens kontrollblokk-register (R14) med gjeldende stakkpeker (SP) med CMPQ. Hvis plassen er utilstrekkelig, hopper (JBE) programmet til inngangspunktet 0x468f95 for stakkutvidelse.
- Lagrer den forrige basepekeren på stakken med PUSHQ BP.
- Kopierer gjeldende stakkpeker (SP) til basepekerregisteret (BP) for å fastsette stakkens referansepunkt ved funksjonsstart.
- Deretter allokeres 16 byte lokal variabelplass på stakken (SUBQ $0x10, SP), og NOPL brukes til å fylle ut med virtuelle instruksjoner for å utføre justering mot CPU-cachen.
- For å synkronisere den interne strengutskriften til standard output kaller Go-kjøretiden runtime.printlock(SB) og tar låsen.
- Med LEAQ-instruksjonen lagres startadressen til strengen konstanten ("Hello World") i AX, som etter Go ABI-spesifikasjonen brukes som første parameter, i et generelt register.
- Deretter lagres verdien som angir strengens lengde i BX, som er det andre parameterregisteret (MOVL $0xb, BX, altså 11 i desimal).
- Kaller runtime.printstring(SB) og skriver ut til konsollen basert på informasjonen i AX (databaseadresse) og BX (lengde).
- For linjeskift kalles runtime.printnl(SB).
- Siden utskriften er fullført, frigjøres låsen via runtime.printunlock(SB).
- ADDQ $0x10, SP gjenoppretter de 16 byte med stakkminne som ble allokert.
- POPQ BP gjenoppretter den opprinnelige basepekeren.
- RET returnerer kontrollen til stedet der funksjonen ble kalt.
- Hvis stakkontrollen i starten viste at plassen var utilstrekkelig, kalles runtime.morestack_noctxt.abi0(SB) på adressen 0x468f95, slik at stakkjøretiden utvides dynamisk, som man forventer av et administrert språk.
- Når stakkutvidelsen er fullført, hopper (JMP) programmet tilbake til inngangspunktet for main.main(SB). Som vist er assemblerkoden for forretningslogikken ganske tydelig, og den er kun supplert med et tynt lag av kjøretidshåndtering.
Når optimalisering er avslått
Formen over er resultatet av at Go-kompilatoren automatisk inlinet de to separate funksjonene og optimaliserte dem. For læringsformål ønsker vi imidlertid i dette tilfellet å unngå å inline sayHello. For å oppnå dette kompileres kildekoden med følgende flagg.
1go build -gcflags="-l" main.go
2
Når vi skriver ut resultatet i terminalen, finner vi repeterte assemblerkodeblokker.
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
Når inlining er deaktivert, settes MOVQ-instruksjoner inn som laster verdiene for parametrene (AX, BX) tilbake til stakkforskyvninger som 0x20(SP), for å bevare dem i samsvar med funksjonskallkonvensjonen. Det vil si at det er bekreftet at det kompilatoren optimaliserer, nettopp er slike unødvendige minneflytt-operasjoner og kalloverhead.
Neste gang
Neste gang skal vi behandle if- og switch-setninger i Go. Hvis tiden tillater det senere, planlegger jeg også å analysere kjøretidsseksjonene i Go.