GoSuda

Análisis de la estructura en tiempo de ejecución de los lenguajes gestionados y del ensamblador AMD64 de los binarios de Go

By Lee Yunjin views ...

¿Qué es un managed language?

Un managed language es un lenguaje que, a diferencia de los unmanaged languages, es decir, aquellos que solo ejecutan la lógica escrita por el programador sin apartarse significativamente de ella, ejecuta en el runtime tareas como GC, optimizaciones en tiempo de ejecución, green threads y el manejo de concurrency, de modo que el usuario no necesita realizar una gestión de bajo nivel y riesgosa. En este tipo de lenguajes, existe la ventaja de que el desarrollador puede concentrarse por completo en la lógica de negocio, pero, por otro lado, el comportamiento real del programa puede diferir de la intuición del programador, por lo que en ocasiones es necesario un ajuste fino del runtime. En primer lugar, examinaremos el lenguaje Go, que entre los managed languages es el que más fielmente sigue una filosofía minimalista y cuyo ensamblador resulta más directo.

Estructura binaria de Go

.text.data.gopclntab, .typelink, etc.
Código de máquina a ejecutarDatos a almacenarSecciones del runtime del lenguaje

Go no traduce el código escrito por el usuario a código de máquina de forma uno a uno, por lo que la lógica de la sección .text está estrechamente relacionada con las secciones del runtime del lenguaje. Además, funciones que el usuario no escribió, como runtime.printnl(), se añaden al ensamblador de la sección .text. Mediante esta inserción automática de código, Go ayuda a liberar al desarrollador de la gestión manual.

Observación únicamente de la función main en Go

En primer lugar, escribiremos un programa de ejemplo main.go y observaremos desde main en una máquina AMD64.

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

Después, lo compilamos así.

1go build main.go
2

Go ofrece go tool para facilitar la depuración de bajo nivel. Para ver únicamente el ensamblador correspondiente a la función main del paquete main, introducimos esta instrucción.

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

Ensamblador

 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
  • Compara el espacio disponible en el marco de pila de la goroutine actual mediante CMPQ, entre el valor del stack guard que se encuentra dentro del registro del bloque de control de la goroutine (R14) y el puntero de pila actual (SP). Si el espacio es insuficiente, salta (JBE) a la dirección 0x468f95, que es el Entrypoint para la expansión de la pila.
  • Inserta el base pointer anterior en la pila mediante PUSHQ BP para guardarlo.
  • Copia el puntero de pila actual (SP) en el registro del base pointer (BP) para fijar la referencia de la pila al inicio de la función.
  • A continuación, reserva 16 bytes de espacio de pila para variables locales (SUBQ $0x10, SP) y utiliza NOPL para rellenar con instrucciones virtuales y realizar la alineación para la caché de la CPU.
  • Llama a runtime.printlock(SB) para adquirir el lock que sincroniza la salida estándar de cadenas internas del runtime de Go.
  • Mediante la instrucción LEAQ, almacena en AX, que según la convención ABI de Go es el primer parámetro, la dirección de inicio de la cadena constante ("Hello World").
  • Después, guarda en BX, el segundo registro de parámetros, el valor que representa la longitud de la cadena (MOVL $0xb, BX, es decir, 11 en decimal).
  • Llama a runtime.printstring(SB) para imprimir en la consola con base en la información de AX (dirección de los datos) y BX (longitud) que se le ha pasado.
  • Llama a runtime.printnl(SB) para realizar el salto de línea.
  • Como la salida ha finalizado, libera el lock mediante runtime.printunlock(SB).
  • Restaura la memoria de pila de 16 bytes reservada mediante ADDQ $0x10, SP.
  • Restaura el base pointer original mediante POPQ BP.
  • Devuelve el control al punto desde el que se llamó a la función mediante RET.
  • Si en la verificación inicial de la pila faltaba espacio, llama a runtime.morestack_noctxt.abi0(SB), ubicada en la dirección 0x468f95, para ampliar dinámicamente la pila del runtime, como corresponde a un managed language.
  • Cuando la expansión de la pila finaliza, vuelve (JMP) al punto de entrada de main.main(SB). Como se observa, el ensamblador de la lógica de negocio es bastante claro y presenta únicamente una gestión ligera añadida por el runtime.

Cuando no hay optimización

La forma anterior es el resultado de que el compilador de Go haya realizado automáticamente inlining de las dos funciones separadas para optimizarlas. Sin embargo, con fines de aprendizaje, en este caso impediremos que sayHello sea objeto de inlining. Para ello, compilamos el código con la siguiente flag.

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

Si mostramos el resultado en la terminal, se observan fragmentos de ensamblador duplicados.

 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

Al desactivar el inlining, para preservar los parámetros (AX, BX) conforme a la convención de llamada de funciones, se insertan operaciones MOVQ que vuelven a cargar los valores en desplazamientos del puntero de pila como 0x20(SP). En otras palabras, se confirma que lo que optimiza el compilador son precisamente estas operaciones innecesarias de movimiento de memoria y la sobrecarga de las llamadas a función.

Próxima sesión

En la próxima sesión trataremos las sentencias if y switch en Go. Si dispongo de tiempo más adelante, también analizaré las secciones del runtime de Go.