Stack alignment in x64 assembly

what is the value of 28h (decimal 40), which is subtracted from rsp , calculated as follows:

  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 

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

In my opinion, I would only have to subtract 20h , since each value I use takes 8 bytes in 4, it's 20h . therefore, why is 28h subtracted and how does this result in 16-byte alignment?

see also Does the stack space save for functions with less than four arguments?

+8
assembly
Oct 02 '13 at 0:45
source share
2 answers

I believe, because before the main is called, the stack is aligned. Then, after the call act of call was to insert an 8-byte pointer (the address of the caller) onto the stack. So, at the beginning of main , these are 8 bytes from alignment of 16 bytes. So instead of 20h you need 28h , bringing the actual value to 28h + 8h (from call ) or 30h . Alignment. :)

+9
Oct 02 '13 at 1:19
source share

I came across the same case. Tried lurker answer and was ok. Some code was added later (by the way, I use my own compiler) and there were problems.

The problem was that the shadow space address ended with 8 on the stack. When the shadow space address ended with 0 ("Stack aligned on 16 bytes"), the call was in order. Adding 8 bytes will crash the application in my last case.

+1
Jan 17 '15 at 9:40
source share



All Articles