Menu
I had a mysterious bus error that occurred, on a x86 (32-bit) platform, when running code compiled with gcc-4.8.1 with -march=pentium4. I traced the problem to an SSE instruction:
movdqa %xmm5,0x50(%esp)
with esp = 0xbfffedac. movdqa requires the address to be 16-byte aligned, which is not the case here, thus the bus error.
The problem does not occur if compiling with -march=native (this is a Core-i3 processor).
As far as I know, the only stack alignment guaranteed on Linux/x86 is 4-byte. Thus, it seems weird that the code generator should choose to use movdqa, without some kind of alignment check, even though there is an instruction movdqu for possibly unaligned accesses.
So, this looks like there is a bug in gcc.
I'm not an expert on SSE and x86 ABI, and I'd appreciate feedback before I send a bug report.
653
"Stack alignment" just means the address of the stack (SP or ESP) is a multiple of the machine word size (so always divisible by 8 for 64-bit mode, 4 for 32-bit, 2 for 16-bit).
All x86 architectures use a stack as a temporary storage area in RAM that allows the processor to quickly store and retrieve data in memory. The current top of the stack is pointed to by the esp register.
IIRC, stack alignment is when variables are placed on the stack "aligned" to a particular number of bytes. So if you are using a 16 bit stack alignment, each variable on the stack is going to start from a byte that is a multiple of 2 bytes from the current stack pointer within a function.
On x86, the stack pointer is stored in the register called "rsp" (Register: Stack Pointer).
Now the default in gcc is -mpreferred-stack-boundary=4 (16-byte alignment), which sets -mincoming-stack-boundary=4.
Problems can thus occur if gcc code using SSE is called from code generated by other compilers which have different stack alignment assumptions, such as OCaml (see discussion on the OCaml bug tracker).
56
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
