3 ms·
Particularly insidious if you don't stick to the 16 byte stack alignment. We had one case where we calling from assembly code back to C, but the asm didn't hon
by rwmj 3y ago
Particularly insidious if you don't stick to the 16 byte stack alignment. We had one case where we calling from assembly code back to C, but the asm didn't honour the C stack alignment. The C code was trying to access some vector variable on the stack and crashed because the compiler generates code assuming %rsp is 16 byte aligned when you enter the function. The stack was only unaligned some of the time and the crash happened very distant from the wrapper, making it a pain to track down. (Asm wrapper has since been fixed).
- derf_ 3y agoIt gets worse than that. On x86-32, you are only guaranteed 8-byte stack alignment, and if you try to use __attribute__((aligned(16)) on a stack variable, gcc just silently fails to enforce the alignment. Or it did 15 years ago when x86-32 was relevant. A lot of times the code works anyway by luck. Until it doesn't. No idea if this was ever fixed.
- Am4TIfIsER0ppos 3y agoWasn't that a Windows limitation? I recall that trouble from ffmpeg having to align the stack for functions that might be called from microsoft compiled code. I recall gcc assuming alignment but no guarantee that you were actually called like that.