3 ms·
The custom entry points look wrong to me. Aren't they breaking the rules over stack alignment when calling functions? Specifically, that rip is supposed to be c
by josephcsible 2y ago
The custom entry points look wrong to me. Aren't they breaking the rules over stack alignment when calling functions? Specifically, that rip is supposed to be congruent to 8 mod 16 at the beginning of a function, and supposed to be divisible by 16 right before a call instruction. The problem is that when code execution starts at the entry point, rip is divisible by 16, but by writing it as a C function, the compiler will assume it's off by 8 from what it actually is.
- oguz-ismail 2y agoDoes it matter unless you're reading a float from varargs? What else can it break?
- josephcsible 2y agoI don't know exactly what, but I know there is more than just that, because calling printf breaks with a misaligned stack even when you're not passing it any floating-point arguments. And even if it doesn't break anything for you today, you're basically committing UB by violating the compiler's assumptions.
- ptspts 2y agoAren't there GCC command-line flags to specify alignment assumptions?
- josephcsible 2y agoYes (see https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.html https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.ht...), but this article doesn't use them.
- saagarjha 2y agoCode that uses vector registers
- fsmv 2y agoThis is from the SysV calling convention not x86 itself. The CPU can do unaligned just fine. You don't have to use the calling convention when not calling out to a library.
- josephcsible 2y agoYou're right that it's not inherent to the architecture, but even if you're only calling your own code, if your own code is written in C, then GCC will assume it too, unless you use command-line arguments or attributes to tell it otherwise, neither of which is being done here.