mirrors/lfs-ru
3
0
Fork 0
mirror of https://github.com/Poltern/lfs-ru.git synced 2024-10-18 11:50:21 +03:00
Code Issues Packages Projects Releases Wiki Activity

gcc: Don't decrease the stack limit

Browse Source 
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.
This commit is contained in:
Poltern 2024-08-28 10:31:52 +05:00
parent 18ce97f095
commit f7e58b2233
1 changed files with 8 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
chapter08/gcc.xml
View File

@ -135,12 +135,16 @@ cd build</userinput></screen>
где x - количество ядер процессора в вашей системе.</para> где x - количество ядер процессора в вашей системе.</para>
</important> </important>
<para>Известно, что один набор тестов GCC переполняет стек по умолчанию, поэтому увеличьте <para>GCC может потребоваться больше места в стеке для компиляции некоторых сложных шаблонов
размер стека перед запуском тестов:</para> кода. В качестве меры предосторожности для хост-дистрибутивов с жестким ограничением стека
явно установите неограниченный жесткий предел. В большинстве хост-дистрибутивов (и в собранной
LFS) жесткий предел по умолчанию неограничен, но нет ничего плохого в том, чтобы установить
его явно. Также нет необходимости изменять мягкий предел размера стека, поскольку GCC автоматически
установит для него соответствующее значение, если это значение не превышает жесткий предел:</para>
<screen><userinput remap="test">ulimit -s 32768</userinput></screen> <screen><userinput remap="test">ulimit -s -H unlimited</userinput></screen>
<para>Теперь удалите /исправьте несколько известных ошибок тестирования:</para> <para>Теперь удалите/исправьте несколько известных ошибок тестирования:</para>
<screen><userinput remap="test">sed -e '/cpython/d' -i ../gcc/testsuite/gcc.dg/plugin/plugin.exp <screen><userinput remap="test">sed -e '/cpython/d' -i ../gcc/testsuite/gcc.dg/plugin/plugin.exp
sed -e 's/no-pic /&amp;-no-pie /' -i ../gcc/testsuite/gcc.target/i386/pr113689-1.c sed -e 's/no-pic /&amp;-no-pie /' -i ../gcc/testsuite/gcc.target/i386/pr113689-1.c