Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x86-symbolic: Stack alignment #436

Closed
langston-barrett opened this issue Sep 17, 2024 · 4 comments · Fixed by #437
Closed

x86-symbolic: Stack alignment #436

langston-barrett opened this issue Sep 17, 2024 · 4 comments · Fixed by #437

Comments

@langston-barrett
Copy link
Contributor

On the subject of the stack under the x86_64 SysV ABI, the OSDev wiki says:

The stack is 16-byte aligned just before the call instruction is called.

We should ensure that the functions introduced in #433 properly establish this precondition.

@langston-barrett
Copy link
Contributor Author

The "System V Application Binary Interface x86-64 Architecture Processor Supplement Draft Version 0.99.6" section 3.2.2 "The Stack Frame" is a bit more specific on what the above means:

The end of the input argument area shall be aligned on a 16 [...] byte boundary. In other words, the value (%rsp + 8) is always a multiple of 16 when control is transferred to the function entry point.

Note that the standard function prelude involves push %rbp, after which %rsp will be 16-byte aligned again (though this prelude is left out with -fomit-frame-pointer).

In 3.2.3 "Parameter Passing", it further says:

The size of each argument gets rounded up to eightbytes [sic]. Therefore the stack will always be eightbyte aligned.

@sauclovian-g
Copy link
Contributor

Er... I thought -fomit-frame-pointer was the default on x86_64 (not that this is really relevant)

@langston-barrett
Copy link
Contributor Author

Er... I thought -fomit-frame-pointer was the default on x86_64 (not that this is really relevant)

Yeah, I think you're right! I added that comment because I saw it while I was reading about this, and found it helpful for understanding why it can often be unnecessary for the compiler to insert padding before calls.

@sauclovian-g
Copy link
Contributor

True enough...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants