GoSuda

Analyse der Laufzeitstruktur verwalteter Sprachen und des AMD64-Assemblers von Go-Binärdateien

By Lee Yunjin views ...

Was ist eine verwaltete Sprache?

Eine verwaltete Sprache ist eine Sprache, die im Gegensatz zu unverwalteten Sprachen, also Sprachen, die den vom Programmierer geschriebenen Ablauf weitgehend nur ausführen, GC, Laufzeitoptimierungen, Green Threads, Nebenläufigkeitsverarbeitung und Ähnliches zur Laufzeit ausführt, sodass Benutzer keine gefährliche Verwaltung auf niedriger Ebene durchführen müssen. Bei solchen Sprachen besteht der Vorteil, dass man sich ausschließlich auf die Geschäftslogik konzentrieren und vollständig in die Entwicklung eintauchen kann; andererseits kann sich das tatsächliche Verhalten eines Programms vom Erwarten des Programmierers unterscheiden, weshalb mitunter eine präzise Laufzeitoptimierung erforderlich ist. Zunächst betrachten wir unter den verwalteten Sprachen die Sprache Go, die der minimalistischen Philosophie am treuesten bleibt und deren Assembler ehrlich ist.

Binärstruktur der Sprache Go

.text.data.gopclntab, .typelink usw.
Auszuführender MaschinencodeZu speichernde DatenLaufzeitabschnitte der Sprache

Da Go den vom Benutzer eingegebenen Code nicht 1:1 in Maschinencode übersetzt, ist die Logik im .text-Abschnitt eng mit den Laufzeitabschnitten der Sprache verbunden. Außerdem werden im Assembler des .text-Abschnitts Funktionen wie runtime.printnl() hinzugefügt, die der Benutzer nicht selbst geschrieben hat. Durch diese automatische Codeeinfügung befreit Go den Entwickler von der manuellen Verwaltung.

Nur den Teil der main-Funktion in Go betrachten

Zunächst schreiben wir ein einfaches Beispielquellprogramm main.go und betrachten main ausgehend vom AMD64-Rechner.

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

Anschließend wird wie folgt gebaut.

1go build main.go
2

Für einfaches systemnahes Debugging unterstützt Go das go tool. Um im go tool nur so viel Assembler des main-Pakets wie die main-Funktion anzuzeigen, gibt man diesen Befehl ein.

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
  • Es wird mit CMPQ der Stapelschutzwert im Goroutine-Kontrollblockregister (R14) mit dem aktuellen Stapelzeiger (SP) verglichen, um zu prüfen, ob der Speicherplatz für den Goroutine-Stapelrahmen ausreicht. Falls nicht, springt das Programm (JBE) zum Eintrittspunkt 0x468f95 für die Stapelerweiterung.
  • Mit PUSHQ BP wird der vorherige Basiszeiger auf dem Stapel gesichert.
  • Der aktuelle Stapelzeiger (SP) wird in das Basiszeigerregister (BP) kopiert, wodurch der Stapelbezugspunkt beim Funktionsstart fixiert wird.
  • Anschließend wird Stapelspeicher für lokale Variablen von 16 Byte reserviert (SUBQ $0x10, SP), und mit NOPL werden Pseudobefehle eingefügt, um die Ausrichtung am CPU-Cache vorzunehmen.
  • Zur Synchronisation der Standardausgabe von Zeichenketten innerhalb der Go-Laufzeit wird runtime.printlock(SB) aufgerufen, um eine Sperre zu setzen.
  • Mit dem Befehl LEAQ wird die Startadresse der als Konstante hinterlegten Zeichenkette ("Hello World") in AX gespeichert, das gemäß der Go-ABI-Spezifikation als erster Parameter dient.
  • Danach wird der Wert, der die Länge der Zeichenkette angibt, im zweiten Parameterregister BX gespeichert. (MOVL $0xb, BX, dezimal 11)
  • Mit runtime.printstring(SB) wird auf Grundlage der übergebenen Informationen in AX (Datenadresse) und BX (Länge) auf die Konsole ausgegeben.
  • Für die Zeilenumbruchbehandlung wird runtime.printnl(SB) aufgerufen.
  • Da die Ausgabe abgeschlossen ist, wird die Sperre über runtime.printunlock(SB) freigegeben.
  • Mit ADDQ $0x10, SP wird der mit 16 Byte reservierte Stapelspeicher wiederhergestellt.
  • Mit POPQ BP wird der ursprüngliche Basiszeiger wiederhergestellt.
  • Über RET wird die Steuerung an die Stelle zurückgegeben, von der die Funktion aufgerufen wurde.
  • Falls bei der anfänglichen Stapelprüfung nicht genügend Platz vorhanden war, wird runtime.morestack_noctxt.abi0(SB) an der Adresse 0x468f95 aufgerufen, um den Stapel zur Laufzeit dynamisch zu erweitern, wie es für eine verwaltete Sprache typisch ist.
  • Nach Abschluss der Stapelerweiterung kehrt die Ausführung mit JMP an den Eintrittspunkt von main.main(SB) zurück. Wie zu sehen ist, ist der Assembler der Geschäftslogik recht übersichtlich und wird nur durch eine dünne Laufzeitverwaltung ergänzt.

Ohne Optimierung

Die obige Form ist das Ergebnis der automatischen Inlining-Optimierung des Go-Compilers, bei der zwei getrennte Funktionen zusammengeführt werden. Zu Lernzwecken werden wir jedoch in diesem Fall verhindern, dass sayHello inlined wird. Dazu kompilieren wir den Quellcode mit folgendem Flag.

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

Im Terminal zeigt sich bei der Ausgabe doppelter Assembler.

 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

Wenn das Inlining deaktiviert wird, werden MOVQ-Operationen eingefügt, die die Parameter (AX, BX) gemäß der Funktionsaufrufkonvention sichern, indem sie Werte erneut an Stapelzeiger-Offsets wie 0x20(SP) laden. Das heißt, es wurde bestätigt, dass der Compiler gerade diese unnötigen Speicherbewegungsoperationen und den Aufrufoverhead optimiert.

Nächstes Mal

Beim nächsten Mal behandeln wir die if- und switch-Anweisungen in Go. Falls sich später Zeit findet, werden wir auch die Abschnitte der Go-Laufzeit analysieren.