Changeset 2ca7fca7


Ignore:
Timestamp:
08/27/2024 08:58:46 AM (2 weeks ago)
Author:
Xi Ruoyao <xry111@…>
Branches:
12.2, multilib, trunk, xry111/arm64, xry111/clfs-ng, xry111/loongarch, xry111/loongarch-12.2, xry111/multilib
Children:
2b76c89, f4f58d4
Parents:
68c63ae
git-author:
Xi Ruoyao <xry111@…> (08/27/2024 08:37:07 AM)
git-committer:
Xi Ruoyao <xry111@…> (08/27/2024 08:58:46 AM)
Message:

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.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • chapter08/gcc.xml

    r68c63ae r2ca7fca7  
    140140    </important>
    141141
    142    <para>One set of tests in the GCC test suite is known to exhaust the default
    143    stack, so increase the stack size prior to running the tests:</para>
    144 
    145 <screen><userinput remap="test">ulimit -s 32768</userinput></screen>
     142    <para>GCC may need more stack space compiling some extremely complex
     143    code patterns.  As a precaution for the host distros with a tight stack
     144    limit, explicitly set the stack size hard limit to infinite.
     145    On most host distros (and the final LFS system) the hard limit is
     146    infinite by default, but there's no harm to set it explicitly anyway.
     147    It's not needed to change the stack size soft limit because GCC will
     148    automatically set it to an appropriate value, as long as the value does
     149    not exceed the hard limit:</para>
     150
     151<screen><userinput remap="test">ulimit -s -H unlimited</userinput></screen>
    146152
    147153    <para>Now remove/fix several known test failures:</para>
Note: See TracChangeset for help on using the changeset viewer.