Alright, my last email had some issues and I'd like to clear that up. The problem with the kernel being 8 byte aligned instead of 16 byte aligned is not a "problem" but rather it'd be wasted stack space to use the full 16 bytes. The kernel also uses no red zone, which is technically against the X86_64 ABI, but this is because the kernel _needs_ no red zone. When it comes to the Linux kernel, X86_64 ABI compatibility can be discarded if it needs to, or if it would somehow be beneficial otherwise. SSE and SSE2 are also disabled. Technically, in order for the Linux kernel to be 100% X86_64 ABI compatible, it'd need not just 16 byte alignment but several features that are disabled at compile-time, so the kernel is special when it comes to ABI compatibility.
With that being said, RTAI's libm in kernel space is technically against the kernel's _own_ ABI as we are using SSE+SSE2 and our modules are 16 byte aligned, instead of 8. As long as there is no misalignment however, this will not cause a GPF. In order for RTAI's libm to be 100% compatible with the Linux kernel, you'd need a magical solution to do high-precision floating-point in kernel space without any SSE, SSE2, using 8 byte aligned stacks, no x87 either, and build it the exact same way the rest of the kernel is built. The solution here is the same solution that was accepted into the AMDGPU driver, so it's really not that bad of a fix. Sometimes you need to use SSE instructions, and just by that alone, you're going against the kernel. With the CFLAGS where they are now, the compatibility concern and the associated crash can be discarded and considered as permanently solved, this is the best it can get. Alec _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
