assembly - pelicula - Alineación de pila en ensamblaje x64

assembly pelicula

Question

cómo se calcula el valor de 28h (decimal 40) que se resta de rsp en lo siguiente:

    option casemap:none

    includelib kernel32.lib
    includelib user32.lib

externdef MessageBoxA : near
externdef ExitProcess : near

    .data

text    db ''Hello world!'', 0
caption db ''Hello x86-64'', 0

    .code

main proc
    sub rsp, 28h        ; space for 4 arguments + 16byte aligned stack
    xor r9d, r9d        ; 4. argument: r9d = uType = 0
    lea r8, [caption]   ; 3. argument: r8  = caption
    lea rdx, [text]     ; 2. argument: edx = window text
    xor rcx, rcx        ; 1. argument: rcx = hWnd = NULL
    call MessageBoxA
    xor ecx, ecx        ; ecx = exit code
    call ExitProcess
main endp

    end

de: http://www.japheth.de/JWasm/Win64_1.html

Según tengo entendido, solo tendría que restar 20h ya que cada valor que estoy usando toma 8 bytes en 4 es 20h . 28h ¿por qué se restan 28h y cómo resulta eso en la alineación de 16 bytes?

ver también ¿Se reserva el espacio de pila necesario para funciones de menos de cuatro argumentos?

Answer 1

Creo que es porque antes de que se llame a main , la pila está alineada. Luego de la call , el acto de la call era presionar un puntero de 8 bytes (dirección de la persona que llama) en la pila. Por lo tanto, al principio de main , está a 8 bytes de la alineación de 16 bytes. Por lo tanto, en lugar de las 20h , necesitas 28h , lo que lleva el total real a 28h + 8h (de la call ) o 30h . Alineación. :)

Answer 2

Me encontré con el mismo caso. Intenté la respuesta de lurker y estaba bien. Más tarde agregué un código (por cierto, estoy usando mi propio compilador) y tuve problemas.

El problema era que la dirección del espacio sombra estaba terminando con 8 en la pila. Cuando la dirección del espacio sombreado terminaba con 0 ("Pila alineada en 16 bytes"), la llamada estaba OK. Agregar 8 bytes bloqueará la aplicación en mi último caso.