From 148511312891f05034be13900cae434e0414457f Mon Sep 17 00:00:00 2001
From: Thomas Trepl <thomas@linuxfromscratch.org>
Date: Fri, 8 Nov 2024 13:18:30 +0100
Subject: [PATCH] Add explanation

---
 chapter08/glibc.xml | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/chapter08/glibc.xml b/chapter08/glibc.xml
index efc9318c1..03d427031 100644
--- a/chapter08/glibc.xml
+++ b/chapter08/glibc.xml
@@ -638,7 +638,37 @@ CXX="g++ -m32 -mstackrealign" \
 
     <para>Adding the <literal>-mstackrealign</literal> flag helps to
       overcome issues with old binaries which cannot be recompiled
-      on the actual OS.</para>
+      on the actual OS. Those issues were reported for 
+      <application>Steam</application>.</para>
+
+    <!-- Thanks to xry111 for explaining the technical background: -->
+    <para>Today the x86-32 SysV psABI (used by all Linux programs)
+      mandates a 16-byte alignment of the stack frame, so the routines
+      using SSE will save/load SSE vectors onto/from the stack using a
+      <literal>movaps</literal> instruction (which only works with
+      aligned addresses, but faster than its counterpart allowing
+      unaligned addresses, <literal>movups</literal>).</para>
+    <para>But some really old x86-32 Linux binaries (compiled about
+      15 years ago), and all Windows x86-32 binaries only aligns the
+      stack frame to 4-byte. Thus, when it calls a SSE routine in LFS
+      built without <literal>-mstackrealign</literal>, the
+      <literal>movdqa</literal> instruction fails with a General
+      Protection Error and the Linux kernel terminates the process
+      with a SIGSEGV.</para>
+    <para>It is not clear why this seems to be an issue with Glibc only.
+      <command>gcc -m32</command> does <emphasis>not</emphasis> turn off SSE (because
+      it means "building a 32-bit program for x86_64" instead of
+      "building a program for i686," and all x86_64 CPU have SSE), so
+      every library can use SSE. <application>Steam</application> has
+      an issue here, but <application>Wine</application> has not.
+      Maybe <application>Wine</application> evades the issue by building
+      most libraries as Windows DLLs using <application>mingw-gcc</application> (which enables
+      <literal>-mstackrealign</literal> by default) instead of relying
+      on the system library, but it still uses the system libc.</para>
+    <para>In theory, the <literal>-mstackrealign</literal> should be
+      applied for all m32 libraries but actually, the only issue
+      reported so far can be fixed by adding it to glibc in the above
+      command only.</para>
 
     <para>Compile the package:</para>