From 2ca7fca7998c2ac7ebfa36af7d2ef15eae9a33e9 Mon Sep 17 00:00:00 2001 From: Xi Ruoyao Date: Tue, 27 Aug 2024 16:37:07 +0800 Subject: [PATCH] gcc: Don't decrease the stack limit I've had doubts on this "ulimit -s 32768" command for years. After reading GCC code (libiberty/stack-limit.c) I'm pretty sure this command is not doing what we expected. In a typical Linux distro, the default "soft" stack limit is 8 MiB and the default "hard" stack limit is infinite. And GCC will automatically increase the soft limit to 64 MiB if the original soft limit is smaller than 64 MiB, and the hard limit is at least 64 MiB. So with a typical default configuration, the real stack limit of GCC is 64 MiB. But our "ulimit -s 32768" command sets both the soft limit and the hard limit to 32 MiB. Thus we are actually *decreasing* the real stack limit. Fortunately this has not caused any test failures, but it's just wrong (contradicting with the explanation of the command). Thus just raise the hard limit to infinite in case the host distro uses a not so typical configuration where the hard limit is tight, and let GCC to set up the soft limit to the expected value on its own. It's more future-proof than "ulimit -s 65536" in case GCC changes the expected stack limit in the future. It should be safe to make the change in freeze because in jhalfs it only affects the test suite, and even in a manual build the user can skip this command if not running the GCC test suite. --- chapter08/gcc.xml | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/chapter08/gcc.xml b/chapter08/gcc.xml index 971394527..ad60089b8 100644 --- a/chapter08/gcc.xml +++ b/chapter08/gcc.xml @@ -139,10 +139,16 @@ cd build command below, where x is the number of CPU cores on your system. - One set of tests in the GCC test suite is known to exhaust the default - stack, so increase the stack size prior to running the tests: + GCC may need more stack space compiling some extremely complex + code patterns. As a precaution for the host distros with a tight stack + limit, explicitly set the stack size hard limit to infinite. + On most host distros (and the final LFS system) the hard limit is + infinite by default, but there's no harm to set it explicitly anyway. + It's not needed to change the stack size soft limit because GCC will + automatically set it to an appropriate value, as long as the value does + not exceed the hard limit: -ulimit -s 32768 +ulimit -s -H unlimited Now remove/fix several known test failures: