Skip to content

Using an unaligned stack #15

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

Open
josephlr opened this issue Sep 23, 2020 · 2 comments
Open

Using an unaligned stack #15

josephlr opened this issue Sep 23, 2020 · 2 comments

Comments

@josephlr
Copy link

In #2 there was discussion about how inline assembly interacts with the stack, and it was decided that:

  • nostack => option one: the stack is unusable, don't even look as rsp.
  • default => option five: the stack is aligned and can be used (you just have to restore things when you exit the asm! block_.

I'm interested in option four: the stack can be used, but isn't necessarily aligned. This comes up a bunch in the x86_64 crate, where we make frequent use of PUSH and POP (so we need the stack to be valid) but don't need the stack to have a particular alignment (example).

Do we see this being a common use case? Would a options(unaligned_stack) make sense?

How would this interact with LLVM's alignstack? We might be able to avoid setting alignstack if the unaligned_stack option is used. In LLVM, does not setting alignstack mean that the stack is potentially invalid?

@Amanieu
Copy link
Member

Amanieu commented Sep 23, 2020

At the moment LLVM only exposes alignstack which only gives us the choice between those two options.

Note that on x86_64 you also have to take the red zone into account, which allows the compiler to store data past the stack pointer. alignstack is the only way to prevent the compiler from putting data in the red zone which would be clobbered by a push.

@josephlr
Copy link
Author

alignstack is the only way to prevent the compiler from putting data in the red zone which would be clobbered by a push.

That makes perfect sense. We switched to asm! and I initially thought the new generated code was a regression, but it turns out we just weren't using llvm_asm! correctly (as we would PUSH without specifying alignstack). Yet another reason the new asm! is great!

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

No branches or pull requests

2 participants