Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[libcxx][libcxxabi] Fix build for OpenBSD #92186

Merged
merged 1 commit into from
May 17, 2024

Conversation

Ericson2314
Copy link
Member

@Ericson2314 Ericson2314 commented May 14, 2024

@Ericson2314 Ericson2314 requested review from a team as code owners May 14, 2024 21:59
@llvmbot llvmbot added libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. libc++abi libc++abi C++ Runtime Library. Not libc++. labels May 14, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented May 14, 2024

@llvm/pr-subscribers-libcxxabi

@llvm/pr-subscribers-libcxx

Author: John Ericson (Ericson2314)

Changes

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

3 Files Affected:

  • (modified) libcxx/src/atomic.cpp (+12-2)
  • (modified) libcxx/src/chrono.cpp (+3-1)
  • (modified) libcxxabi/src/cxa_guard_impl.h (+15-1)
diff --git a/libcxx/src/atomic.cpp b/libcxx/src/atomic.cpp
index 2b67685c8a0a1..e0a5be86daab9 100644
--- a/libcxx/src/atomic.cpp
+++ b/libcxx/src/atomic.cpp
@@ -25,16 +25,26 @@
 #  if !defined(SYS_futex) && defined(SYS_futex_time64)
 #    define SYS_futex SYS_futex_time64
 #  endif
+#  define _LIBCPP_FUTEX(...) syscall(SYS_futex, __VA_ARGS__)
 
 #elif defined(__FreeBSD__)
 
 #  include <sys/types.h>
 #  include <sys/umtx.h>
 
+# define _LIBCPP_FUTEX(...) syscall(SYS_futex, __VA_ARGS__)
+
+#elif defined(__OpenBSD__)
+
+// OpenBSD has no indirect syscalls
+#  define _LIBCPP_FUTEX(...) futex(__VA_ARGS__)
+
 #else // <- Add other operating systems here
 
 // Baseline needs no new headers
 
+# define _LIBCPP_FUTEX(...) syscall(SYS_futex, __VA_ARGS__)
+
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
@@ -44,11 +54,11 @@ _LIBCPP_BEGIN_NAMESPACE_STD
 static void
 __libcpp_platform_wait_on_address(__cxx_atomic_contention_t const volatile* __ptr, __cxx_contention_t __val) {
   static constexpr timespec __timeout = {2, 0};
-  syscall(SYS_futex, __ptr, FUTEX_WAIT_PRIVATE, __val, &__timeout, 0, 0);
+  _LIBCPP_FUTEX(__ptr, FUTEX_WAIT_PRIVATE, __val, &__timeout, 0, 0);
 }
 
 static void __libcpp_platform_wake_by_address(__cxx_atomic_contention_t const volatile* __ptr, bool __notify_one) {
-  syscall(SYS_futex, __ptr, FUTEX_WAKE_PRIVATE, __notify_one ? 1 : INT_MAX, 0, 0, 0);
+  _LIBCPP_FUTEX(__ptr, FUTEX_WAKE_PRIVATE, __notify_one ? 1 : INT_MAX, 0, 0, 0);
 }
 
 #elif defined(__APPLE__) && defined(_LIBCPP_USE_ULOCK)
diff --git a/libcxx/src/chrono.cpp b/libcxx/src/chrono.cpp
index c5e827c0cb59f..e7d6dfbc22924 100644
--- a/libcxx/src/chrono.cpp
+++ b/libcxx/src/chrono.cpp
@@ -31,7 +31,9 @@
 #  include <sys/time.h> // for gettimeofday and timeval
 #endif
 
-#if defined(__APPLE__) || defined(__gnu_hurd__) || (defined(_POSIX_TIMERS) && _POSIX_TIMERS > 0)
+// OpenBSD does not have a fully conformant suite of POSIX timers, but
+// it does have clock_gettime and CLOCK_MONOTONIC which is all we need.
+#if defined(__APPLE__) || defined(__gnu_hurd__) || defined(__OpenBSD__) || (defined(_POSIX_TIMERS) && _POSIX_TIMERS > 0)
 #  define _LIBCPP_HAS_CLOCK_GETTIME
 #endif
 
diff --git a/libcxxabi/src/cxa_guard_impl.h b/libcxxabi/src/cxa_guard_impl.h
index 7b140d3c36045..320501cb85938 100644
--- a/libcxxabi/src/cxa_guard_impl.h
+++ b/libcxxabi/src/cxa_guard_impl.h
@@ -47,6 +47,9 @@
 #include "__cxxabi_config.h"
 #include "include/atomic_support.h" // from libc++
 #if defined(__has_include)
+#  if __has_include(<sys/futex.h>)
+#    include <sys/futex.h>
+#  endif
 #  if __has_include(<sys/syscall.h>)
 #    include <sys/syscall.h>
 #  endif
@@ -411,7 +414,18 @@ struct InitByteGlobalMutex {
 //                         Futex Implementation
 //===----------------------------------------------------------------------===//
 
-#if defined(SYS_futex)
+#if defined(__OpenBSD__)
+void PlatformFutexWait(int* addr, int expect) {
+  constexpr int WAIT = 0;
+  futex(reinterpret_cast<volatile uint32_t*>(addr), WAIT, expect, NULL, NULL);
+  __tsan_acquire(addr);
+}
+void PlatformFutexWake(int* addr) {
+  constexpr int WAKE = 1;
+  __tsan_release(addr);
+  futex(reinterpret_cast<volatile uint32_t*>(addr), WAKE, INT_MAX, NULL, NULL);
+}
+#elif defined(SYS_futex)
 void PlatformFutexWait(int* addr, int expect) {
   constexpr int WAIT = 0;
   syscall(SYS_futex, addr, WAIT, expect, 0);

Copy link

github-actions bot commented May 14, 2024

✅ With the latest revision this PR passed the C/C++ code formatter.

- No indirect syscalls on OpenBSD. Instead there is a `futex` function
  which issues a direct syscall.

- monotonic clock is avaialable despite the full POSIX suite of timers
  not being available in its entirety.

  See https://lists.boost.org/boost-bugs/2015/07/41690.php and
  boostorg/log@c98b1f4
  for a description of an analogous problem an fix for Boost.
@Ericson2314 Ericson2314 merged commit af7467c into llvm:main May 17, 2024
25 of 26 checks passed
@Ericson2314 Ericson2314 deleted the libcxx-openbsd branch May 17, 2024 20:49
@Ericson2314 Ericson2314 added this to the LLVM 18.X Release milestone May 17, 2024
@Ericson2314
Copy link
Member Author

/cherry-pick af7467c

llvmbot pushed a commit to llvmbot/llvm-project that referenced this pull request May 17, 2024
- No indirect syscalls on OpenBSD. Instead there is a `futex` function
which issues a direct syscall.

- Monotonic clock is available despite the full POSIX suite of timers
not being available in its entirety.

  See https://lists.boost.org/boost-bugs/2015/07/41690.php and
  boostorg/log@c98b1f4
  for a description of an analogous problem and fix for Boost.

(cherry picked from commit af7467c)
@llvmbot
Copy link
Collaborator

llvmbot commented May 17, 2024

/pull-request #92601

@brad0
Copy link
Contributor

brad0 commented May 18, 2024

@Ericson2314 I was looking around regarding this and I also noticed libcxx/src/filesystem/filesystem_clock.cpp and CLOCK_GETTIME.

tstellar pushed a commit to llvmbot/llvm-project that referenced this pull request May 18, 2024
- No indirect syscalls on OpenBSD. Instead there is a `futex` function
which issues a direct syscall.

- Monotonic clock is available despite the full POSIX suite of timers
not being available in its entirety.

  See https://lists.boost.org/boost-bugs/2015/07/41690.php and
  boostorg/log@c98b1f4
  for a description of an analogous problem and fix for Boost.

(cherry picked from commit af7467c)
@ldionne
Copy link
Member

ldionne commented May 21, 2024

Folks, please don't merge without getting an approval from the libc++/libc++abi reviewers in the future. This is the policy we follow in libc++. I've been OOO for the past 10 days so please let me know if somehow this followed a different approval path and I just missed it, but on the surface it looks like this change didn't go through our normal approval process.

About the patch itself: Is there a reason why this is a problem now but wasn't a problem before? Also, we claim to support FreeBSD but we don't claim to support OpenBSD at all, and in order to do that we'd need to have a CI tester running per our policy.

@Ericson2314
Copy link
Member Author

Ericson2314 commented May 22, 2024

Sorry @ldionne. I didn't have so much of an idea of who is or isn't a reviewer, so didn't know anything was proceeding out of the ordinarily.

About the patch itself: Is there a reason why this is a problem now but wasn't a problem before?

I imagine no one tried to build it on OpenBSD before.

Also, we claim to support FreeBSD but we don't claim to support OpenBSD at all, and in order to do that we'd need to have a CI tester running per our policy.

FWIW I have just been cross compiling with Nix so far. I could contribute that but I am not sure whether it would count for building on OpenBSD.

@ldionne
Copy link
Member

ldionne commented May 22, 2024

Screenshot 2024-05-22 at 10 49 38

This shows what approvals are necessary before landing a patch. The review group must have approved (that way no need to know which individuals must have approved).

I imagine no one tried to build it on OpenBSD before.

Ok, so then this patch is adding support for a new platform. We have a policy for doing that explained in https://libcxx.llvm.org/#platform-and-compiler-support. As part of our policy, we require CI to be present for all platforms that we officially support.

Since this is not the case right now and it seems that more patches are coming down the pipeline to support OpenBSD, I would like us to add such support before we proceed with any other OpenBSD support patch. If we can't fulfill our support policy, I would ask to revert this patch.

It's unfortunate that this was cherry-picked to the LLVM 18 release since this is definitely not something I'd consider a bugfix, but we can live with that.

@brad0
Copy link
Contributor

brad0 commented May 25, 2024

About the patch itself: Is there a reason why this is a problem now but wasn't a problem before? Also, we claim to support FreeBSD but we don't claim to support OpenBSD at all, and in order to do that we'd need to have a CI tester running per our policy.

OpenBSD very recently made a change removing syscall(2) otherwise it's built fine for many many years.

@brad0
Copy link
Contributor

brad0 commented May 25, 2024

I imagine no one tried to build it on OpenBSD before.

It's our system compiler / C++ standard library..

@brad0
Copy link
Contributor

brad0 commented May 25, 2024

I imagine no one tried to build it on OpenBSD before.

Ok, so then this patch is adding support for a new platform. We have a policy for doing that explained in https://libcxx.llvm.org/#platform-and-compiler-support. As part of our policy, we require CI to be present for all platforms that we officially support.

It's not a new platform per se. OpenBSD made a local change that broke things. We've been building and using libc++ for many years.

Since this is not the case right now and it seems that more patches are coming down the pipeline to support OpenBSD, I would like us to add such support before we proceed with any other OpenBSD support patch. If we can't fulfill our support policy, I would ask to revert this patch.

There are no other patches coming down the pipeline. There is nothing else at all. The one local patch we had for libcxxabi was commited as part of this patch.

@ldionne
Copy link
Member

ldionne commented May 27, 2024

I think I saw #92675 which is also for OpenBSD. Generally speaking, what I'm saying is that we don't officially support platforms for which we have no tests, and OpenBSD currently falls in that category. I think it's great that OpenBSD uses libc++ as its system library and I would like the OpenBSD folks to work on getting us official test coverage on that platform so we can support it as a first class citizen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libc++abi libc++abi C++ Runtime Library. Not libc++. libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.
Projects
Development

Successfully merging this pull request may close these issues.

None yet

4 participants