Re: x86-64: Maintain 16-byte stack alignment
From: Andy Lutomirski <luto@amacapital.net>
Date: 2017-01-12 20:08:31
Also in:
lkml
On Thu, Jan 12, 2017 at 11:51 AM, Linus Torvalds [off-list ref] wrote:
On Thu, Jan 12, 2017 at 6:02 AM, Josh Poimboeuf [off-list ref] wrote:quoted
Just to clarify, I think you're asking if, for versions of gcc which don't support -mpreferred-stack-boundary=3, objtool can analyze all C functions to ensure their stacks are 16-byte aligned. It's certainly possible, but I don't see how that solves the problem. The stack will still be misaligned by entry code. Or am I missing something?I think the argument is that we *could* try to align things, if we just had some tool that actually then verified that we aren't missing anything. I'm not entirely happy with checking the generated code, though, because as Ingo says, you have a 50:50 chance of just getting it right by mistake. So I'd much rather have some static tool that checks things at a code level (ie coccinelle or sparse).
What I meant was checking the entry code to see if it aligns stack
frames, and good luck getting sparse to do that. Hmm, getting 16-byte
alignment for real may actually be entirely a lost cause. After all,
I think we have some inline functions that do asm volatile ("call
..."), and I don't see any credible way of forcing alignment short of
generating an entirely new stack frame and aligning that. Ick. This
whole situation stinks, and I wish that the gcc developers had been
less daft here in the first place or that we'd noticed and gotten it
fixed much longer ago.
Can we come up with a macro like STACK_ALIGN_16 that turns into
__aligned__(32) on bad gcc versions and combine that with your sparse
patch?