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.