Beautiful, that fixed the misalignment issue ergo no GPF hence no crash, WINNING!!! I'll be merging the new-libm branch into master soon (tomorrow after sleep.) Get ready to make new debs, I'm going to bump the kernel patches to the latest of the 4.14 kernel series (after I fix some conflicts.)
I changed nothing except CFLAGS so far, everything else is the same. Consider this fix permanent, and "the right way." https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html -> -mstackrealign -> "Realign the stack at entry. On the x86, the -mstackrealign option generates an alternate prologue and epilogue that realigns the run-time stack if necessary. This supports mixing legacy codes that keep 4-byte stack alignment with modern codes that keep 16-byte stack alignment for SSE compatibility. See also the attribute force_align_arg_pointer, applicable to individual functions." Remember this part? "Warning: When generating code for the x86-64 architecture with SSE extensions disabled, -mpreferred-stack-boundary=3 can be used to keep the stack boundary aligned to 8 byte boundary. Since x86-64 ABI require 16 byte stack alignment, this is ABI incompatible and intended to be used in controlled environment where stack space is important limitation. This option leads to wrong code when functions compiled with 16 byte stack alignment (such as functions from a standard library) are called with misaligned stack. In this case, SSE instructions may lead to misaligned memory access traps. In addition, variable arguments are handled incorrectly for 16 byte aligned objects (including x87 long double and __int128), leading to wrong results. You must build all modules with -mpreferred-stack-boundary=3, including any libraries. This includes the system libraries and startup modules." Well, for GCC versions older than 7, you can't mix double floating point operations that use SSE with -mpreferred-stack-boundary=3, that value needs to be 4 in order to compile. The entire kernel just about is built without SSE, and without doubles. With -mpreferred-stack-boundary=4 you are now mixing the musl libm math library with a kernel built with a stack boundary of 3, and because of this, we need "support for mixing legacy codes that keep 4-byte stack alignment with modern codes that keep 16-byte stack alignment for SSE compatibility." Without -mstackrealign, the stack is not being re-aligned (makes sense) and depending on your CPU, this will cause a fault. For some reason, at least AMD Ryzen processors are immune to a misaligned stack that involves xmm0 in kernel space which is why I can't reproduce the crash. "This option leads to wrong code when functions compiled with 16 byte stack alignment (such as functions from a standard library) are called with misaligned stack. In this case, SSE instructions may lead to misaligned memory access traps." This "wrong code" and "misaligned memory access traps" is what is causing the crash. This is all fixed with -mstackrealign. This is what I don't get, "variable arguments are handled incorrectly for 16 byte aligned objects (including x87 long double and __int128), leading to wrong results." Why do 16 byte aligned objects lead to wrong results? The X86_64 ABI says that objects should be 16 byte aligned, GCC says you must build all modules that are 8 byte aligned. GCC is going against the X86_64 ABI, and technically so is the Linux kernel. Is Linux seriously broken by design in the sense that you can't use 16 byte aligned objects? If using 16 byte boundaries causes wrong results, when the X86_64 ABI says it should be 16 bytes, WHAT THE FLYING HELL IS GOING ON, AND WHY ISN'T THIS FIXED??? THAT'S A REALLY BIG PROBLEM!!!!!!!!!!!!!!!!! Alec _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
