[lit] Disable ulimit-nodarwin test on FreeBSD

[aokblast]

FreeBSD does not support using ulimit to grow up max file number per
process. This characteristic is inherited by Darwin and thus we pass
this test on FreeBSD as well.

[llvmbot]

@llvm/pr-subscribers-testing-tools

Author: None (aokblast)

Changes

FreeBSD does not support using ulimit to grow up max file size. This characteristic is inherited by Darwin and thus we pass this test on FreeBSD as well.

---

Full diff: https://github.com/llvm/llvm-project/pull/173155.diff

1 Files Affected:

• (modified) llvm/utils/lit/tests/shtest-ulimit-nondarwin.py (+1-1)

diff --git a/llvm/utils/lit/tests/shtest-ulimit-nondarwin.py b/llvm/utils/lit/tests/shtest-ulimit-nondarwin.py
index d5340a7d2efb9..be2627be366ed 100644
--- a/llvm/utils/lit/tests/shtest-ulimit-nondarwin.py
+++ b/llvm/utils/lit/tests/shtest-ulimit-nondarwin.py
@@ -2,7 +2,7 @@
 
 # ulimit does not work on non-POSIX platforms.
 # These tests are specific to options that Darwin does not support.
-# UNSUPPORTED: system-windows, system-cygwin, system-darwin, system-aix, system-solaris
+# UNSUPPORTED: system-windows, system-cygwin, system-darwin, system-aix, system-solaris, system-freebsd
 
 # RUN: not %{lit} -v %{inputs}/shtest-ulimit-nondarwin | FileCheck %s
 

[boomanaiden154]

LGTM. I should probably refactor this at some point after I better understand the landscape of what ulimit features are supported where. The portability of ulimit features in lit turned out to be significantly more complicated than I originally thought.

[aokblast]

LGTM. I should probably refactor this at some point after I better understand the landscape of what ulimit features are supported where. The portability of ulimit features in lit turned out to be significantly more complicated than I originally thought.

Thanks. Adding this simple bypass also helps me learn alot. I have done some experiment yesterday cross multiple systems and get the following conclusions:

1. FreeBSD's RLIM_INFINITY is 1LL << 63 - 1 instead of -1, this means not only the file num test breaks. All tests use RLIM_INFINITY won't output -1 on FreeBSD.
2. FreeBSD's rlim_t is int64_t, while uint64_t, NetBSD, OpenBSD, Linux, Darwin are uint64_t
3. the ulimit is shell builtin command, that means this testcase may not able to run correctly on different shell. When you set different resource, they actually have different uint cross different shells since you set the value by shell but read the raw value from syscall. You have to either read and write the rlimit in python or read and write the rlimit in shell. See: https://github.com/freebsd/freebsd-src/blob/main/usr.bin/limits/limits.c#L59

[boomanaiden154]

FreeBSD's RLIM_INFINITY is 1LL << 63 - 1 instead of -1, this means not only the file num test breaks. All tests use RLIM_INFINITY won't output -1 on FreeBSD.

Yeah. We ran into this issue on Solaris too. I thought this would be portable, but that was just me not reading POSIX closely enough again...

the ulimit is shell builtin command, that means this testcase may not able to run correctly on different shell.

These tests test the implementation of ulimit within the internal shell and all upstream test suites have been migrated to use the lit internal shell at this point, so shell differences should not matter at this point.

[aokblast]

FreeBSD's RLIM_INFINITY is 1LL << 63 - 1 instead of -1, this means not only the file num test breaks. All tests use RLIM_INFINITY won't output -1 on FreeBSD.

Yeah. We ran into this issue on Solaris too. I thought this would be portable, but that was just me not reading POSIX closely enough again...

the ulimit is shell builtin command, that means this testcase may not able to run correctly on different shell.

These tests test the implementation of ulimit within the internal shell and all upstream test suites have been migrated to use the lit internal shell at this point, so shell differences should not matter at this point.
Ahh, ok. Thanks for your explanation. I will wait one more FreeBSD developer accpet this patch before landing this.