[FreeBSD] Adding FreeBSD support #77836

michael-yuji · 2024-11-25T22:53:38Z

This commit adds required conditional compilation blocks to enable building and running
on FreeBSD (tested on x86_64 FreeBSD 14.1-RELEASE-p6).

Also implements FreeBSD synchronization shims using _umtx_op(2)

lin72h · 2024-11-25T22:57:51Z

It's my early Christmas gift. Thanks for working on this.

michael-yuji · 2024-11-26T01:04:52Z

It's my early Christmas gift. Thanks for working on this.

unfortunately this PR alone here is not enough. I do have patches to other swift components to get it fully working and going to PR them to coming weeks. But even with those, you'll need to have a functional swiftc (by bootstrapping a swift 5.8+) on FreeBSD to build them. personally I've done a multi-stages bootstrap until I now have a toolchain ready.

you also need a patch to the base libc++ to workaround this issue

lin72h · 2024-11-26T01:34:18Z

it's very impressive work especially the bootstrap part!

compnerd · 2024-11-26T02:42:02Z

stdlib/public/Platform/SwiftGlibc.h.gyb

@@ -65,6 +65,7 @@ headers = [
  'spawn.h',
  'strings.h',
  'sys/event.h',
+  'sys/extattr.h',


Is this header available universally? I think that this might need to be under a FreeBSD condition.

The gyb expands '${header}' to an include guarded by __has_include, which test if the header can be included. similarly, the Linux specific sys/inotify.h header is also in the list.

#if __has_include(<${header}>) #include <${header}> #endif

You're right, any headers added to this file are just ignored if they don't exist, as there are already some OpenBSD-specific headers.

Have you considered adding a FreeBSD overlay instead? You could take a look at the recent Musl, WASI, and Android overlays for examples.

I know that's more work, but the WASI one isn't so bad, and FreeBSD may not be either.

That's definitely on my radar! I'm not sure yet if I have to bandwidth to include that change in this PR.

We shoulda just called them all import C.

And yeah, the implementation is actually very difficult, especially when C++ gets involved.

Thanks for all the feedback! Sorry for the late reply I was extremely sick for the past 2 weeks.
I certainly agree FreeBSD shouldn't use Glibc. In fact I have been working on the overlay for quite a while now but never gotten into a state I'm perfectly happy about it. More specifically I'd love to follow the Darwin modulemap and make certain C headers replaceable by clang, however it doesn't seems to be possible without making changes to the FreeBSD source tree.

My plan is to put the overlay changes into a separate PR, due to size of diff is quite big and this is already a rather large PR (as you can imagine all instance of where import Glibc occurs needs to be patched).

I have a working implementation ready to go, either committing to this PR, or as a separate PR, depending on what will be more comfortable for you to review. Wdyt @al45tair @ian-twilightcoder @grynspan @finagolfin

This also helps keep my head sane as I've been to maintaining quite a few separate trees of all the swift sub-projects locally to implement various feature for FreeBSD and it's getting quite messy.

I have no opinion either way.

overlay PR created. #79261

finagolfin · 2024-11-26T13:02:35Z

Nice, there is some work to get Swift 6 bootstrapping again, #77815, that you'll want to follow.

Pinging @mhjacobson and @3405691582, who added BSD support before and may be able to help review.

3405691582 · 2024-11-30T20:57:00Z

As a heads up, the code uses LLVM target triples and the build system has a few places where it assumes that the platform calls the architecture with the same name as LLVM does. This isn't a problem for FreeBSD on what LLVM calls x86_64, since they apparently both seem to use the same spelling, but for what LLVM calls aarch64, both OpenBSD and FreeBSD call it arm64. This causes headaches.

In the past, I've tried to keep some meaningful separation between platform spelling and LLVM spelling, but I'm reconsidering that in #77879. You probably won't need to do anything right now for this pr if you're just targeting x86_64, though, and what you have seems good to me, but keep this in mind if you're going to also be working on arm64.

khng300 · 2024-12-01T20:57:16Z

As a heads up, the code uses LLVM target triples and the build system has a few places where it assumes that the platform calls the architecture with the same name as LLVM does. This isn't a problem for FreeBSD on what LLVM calls x86_64, since they apparently both seem to use the same spelling, but for what LLVM calls aarch64, both OpenBSD and FreeBSD call it arm64. This causes headaches.

In the past, I've tried to keep some meaningful separation between platform spelling and LLVM spelling, but I'm reconsidering that in #77879. You probably won't need to do anything right now for this pr if you're just targeting x86_64, though, and what you have seems good to me, but keep this in mind if you're going to also be working on arm64.

Which is not correct for the FreeBSD part. On FreeBSD itself, arm64 is the TARGET, meanwhile aarch64 is the TARGET_ARCH and MACHINE_ARCH. Below is what I got from a build of the FreeBSD tree on my side:

CMD cc -target aarch64-unknown-freebsd15.0 --sysroot=

For reference how we build the -target tuple in the tree:

Makefile.inc1:		MACHINE_ARCH=${TARGET_ARCH}
Makefile:	TARGET=${_TARGET} TARGET_ARCH=${_TARGET_ARCH} ${_MAKEARGS}
Makefile:_TARGET_ARCH=	${TARGET:S/arm64/aarch64/:S/riscv/riscv64/:S/arm/armv7/}
./Makefile.inc1:MACHINE_TRIPLE?=${MACHINE_ARCH:S/amd64/x86_64/}-${MACHINE_TRIPLE_ABI}-freebsd${OS_REVISION}

michael-yuji · 2024-12-02T18:48:55Z

@swift-ci please smoke test

michael-yuji · 2024-12-03T17:56:03Z

@swift-ci please test

grynspan · 2025-02-03T02:17:53Z

include/swift/AST/AutoDiff.h

@@ -422,7 +422,14 @@ class DerivativeFunctionTypeError
  Kind kind;

  /// The type and index of a differentiability parameter or result.
-  using TypeAndIndex = std::pair<Type, unsigned>;
+  /// std::pair does not have a trivial copy constructor on FreeBSD <= 14 for


Could you just change the call sites that are using the constructor? That would simplify the diff.

grynspan · 2025-02-03T02:18:46Z

lib/ClangImporter/ClangImporter.cpp

@@ -2562,6 +2562,10 @@ PlatformAvailability::PlatformAvailability(const LangOptions &langOpts)
  case PlatformKind::visionOSApplicationExtension:
    break;

+  case PlatformKind::FreeBSD:


Can we coalesce the non-Apple cases?

grynspan · 2025-02-03T02:19:11Z

lib/ClangImporter/ClangImporter.cpp

@@ -2680,6 +2687,10 @@ bool PlatformAvailability::treatDeprecatedAsUnavailable(
    // No deprecation filter on xrOS
    return false;

+  case PlatformKind::FreeBSD:


Can we coalesce?

grynspan · 2025-02-03T02:20:15Z

lib/IRGen/TBDGen.cpp

@@ -244,6 +244,8 @@ getLinkerPlatformId(OriginallyDefinedInAttr::ActiveVersion Ver,
    llvm_unreachable("cannot find platform kind");
  case swift::PlatformKind::OpenBSD:
    llvm_unreachable("not used for this platform");
+  case swift::PlatformKind::FreeBSD:
+    llvm_unreachable("not used for this platform");


Can we coalesce? (Also, nitpick, the order of FreeBSD relative to OpenBSD is inconsistent. It's not important in any practical sense, but consistency is a good thing.)

grynspan · 2025-02-03T02:21:06Z

stdlib/public/Platform/Platform.swift

@@ -338,12 +338,12 @@ public var SIG_DFL: sig_t? { return nil }
 public var SIG_IGN: sig_t { return unsafeBitCast(1, to: sig_t.self) }
 public var SIG_ERR: sig_t { return unsafeBitCast(-1, to: sig_t.self) }
 public var SIG_HOLD: sig_t { return unsafeBitCast(5, to: sig_t.self) }
-#elseif os(OpenBSD)
+#elseif os(OpenBSD) || os(FreeBSD)


Nitpick: platform order

grynspan · 2025-02-03T02:25:25Z

stdlib/public/Platform/glibc.modulemap.gyb

@@ -19,7 +19,7 @@
 /// It's not named just Glibc so that it doesn't conflict in the event of a
 /// future official glibc modulemap.
 module SwiftGlibc [system] {
-% if CMAKE_SDK in ["LINUX", "OPENBSD"]:
+% if CMAKE_SDK in ["LINUX", "OPENBSD", "FREEBSD"]:


Nitpick: platform order

grynspan · 2025-02-03T02:25:41Z

stdlib/public/SwiftShims/swift/shims/SwiftStdint.h

@@ -24,7 +24,7 @@

 // Clang has been defining __INTxx_TYPE__ macros for a long time.
 // __UINTxx_TYPE__ are defined only since Clang 3.5.
-#if !defined(__APPLE__) && !defined(__linux__) && !defined(__OpenBSD__) && !defined(__wasi__)
+#if !defined(__APPLE__) && !defined(__linux__) && !defined(__OpenBSD__) && !defined(__FreeBSD__) && !defined(__wasi__)


Nitpick: platf—okay you get the idea

grynspan · 2025-02-03T02:26:39Z

stdlib/public/Synchronization/Mutex/FreeBSDImpl.swift

+@available(SwiftStdlib 6.0, *)
+@frozen
+@_staticExclusiveOnly
+public struct _MutexHandle: ~Copyable {


Does this actually need to be public?

grynspan · 2025-02-03T02:27:30Z

test/Interop/Cxx/stdlib/use-std-optional.swift

@@ -16,7 +16,7 @@ StdOptionalTestSuite.test("pointee") {
  let pointee = nonNilOpt.pointee
  expectEqual(123, pointee)

-#if !os(Linux) // crashes on Ubuntu 18.04 (rdar://113414160)
+#if !os(Linux) && !os(FreeBSD) // crashes on Ubuntu 18.04 (rdar://113414160)


If this is crashing on FreeBSD as well, can you file a GitHub issue or Radar as appropriate and reference it here too?

grynspan · 2025-02-03T02:28:12Z

test/stdlib/DispatchTypes.swift

@@ -27,14 +27,22 @@ if #available(OSX 10.10, iOS 8.0, *) {
 // dispatch/source.h
 _ = DispatchSource.makeUserDataAddSource()
 _ = DispatchSource.makeUserDataOrSource()
+#if !os(FreeBSD)


How is this compiling on Linux right now? Surely whatever guards Linux should guard FreeBSD too.

DispatchSource is basically kqueue wrapper, which exists on FreeBSD and Darwin but not on Linux

Are we sure we want to commit to supporting it at this time, or does it make more sense to leverage future improvements aimed at Linux?

jakepetroules · 2025-02-12T06:13:27Z

I'm considering this a blocker for swiftlang/swift-build#12 since that requires the header file providing access to the xattr functions to be in the modulemap in order to enable xattr support in Swift Build's filesystem implementation.

jakepetroules · 2025-02-13T06:30:32Z

@swift-ci test

egorzhdan

This looks amazing! I have just one comment about a C++ interop test.

test/Interop/Cxx/stdlib/fake-toolchain-module-interface.swift

This commit adds required conditional compilation blocks to enable bulding on FreeBSD (tested on x86_64 FreeBSD 14.1-RELEASE-p6). Also implements FreeBSD synchronization shims using `_umtx_op(2)`

tmmvn · 2025-05-14T03:21:37Z

stdlib/public/core/CTypes.swift

Is this one correct? I recently was working to get 5.10 running on an ARM 64bit VPS FreeBSD 14 box, and I think I had to use arch(aarch64) here to get the compiling to succeed.

Naïve of me to say it, but I'd expect that if the Swift compiler accepts aarch64 then it would treat it as a synonym of arm64.

Yes, they mean the same. IIRC clang uses aarch64 on FreeBSD. I am not sure why.

Strictly speaking, AArch64 is the architecture's name according to Arm Holdings. 🤷 Apple's technically the odd one out, here.

Yeah, we want to be using the name aarch64, not arm64. See another PR here which deals with this topic: #81662

CodingCarpincho · 2025-05-22T20:01:20Z

cmake/modules/SwiftConfigureSDK.cmake

@@ -417,7 +417,7 @@ macro(configure_sdk_unix name architectures)
          message(FATAL_ERROR "unknown arch for ${prefix}: ${arch}")
        endif()
      elseif("${prefix}" STREQUAL "FREEBSD")
-        if(NOT arch MATCHES "(arm64|x86_64)")
+        if(NOT arch MATCHES "(aarch64|arm64|x86_64)")


Should we even keep the arm64 string here? aarch64 seems to be the architecture name that we should be using for 64-bit ARM.

include/swift/AST/AutoDiff.h

CodingCarpincho · 2025-05-29T06:32:36Z

@shahmishal Could you or someone else kick off the CI here so we can get Michael’s work merged?

3405691582 · 2025-05-29T06:49:59Z

@swift-ci please test.

michael-yuji requested a review from a team as a code owner November 25, 2024 22:53

compnerd reviewed Nov 26, 2024

View reviewed changes

michael-yuji requested review from ahoppen, bnbarham, hamishknight, rintaro, QuietMisdreavus, zoecarver, hyp, egorzhdan, Xazax-hun, rjmccall, beccadax, ian-twilightcoder, hborla, slavapestov, xedin and eeckstein as code owners November 29, 2024 01:04

QuietMisdreavus removed their request for review December 2, 2024 17:47

ahoppen removed their request for review December 3, 2024 22:21

grynspan mentioned this pull request Dec 18, 2024

Additional FreeBSD fixes swiftlang/swift-testing#865

Merged

2 tasks

michael-yuji force-pushed the mchiu/freebsd branch from 8c4f0d4 to 65db70b Compare January 26, 2025 09:16

michael-yuji force-pushed the mchiu/freebsd branch from 65db70b to 0f1000b Compare January 26, 2025 09:21

al45tair requested a review from drexin January 28, 2025 11:28

michael-yuji force-pushed the mchiu/freebsd branch from 0f1000b to c22dacb Compare February 2, 2025 04:03

grynspan reviewed Feb 3, 2025

View reviewed changes

jakepetroules mentioned this pull request Feb 12, 2025

Add FreeBSD support swiftlang/swift-build#12

Draft

egorzhdan reviewed Feb 13, 2025

View reviewed changes

test/Interop/Cxx/stdlib/fake-toolchain-module-interface.swift Outdated Show resolved Hide resolved

michael-yuji and others added 4 commits March 14, 2025 02:15

Adding FreeBSD support

0c47c45

This commit adds required conditional compilation blocks to enable bulding on FreeBSD (tested on x86_64 FreeBSD 14.1-RELEASE-p6). Also implements FreeBSD synchronization shims using `_umtx_op(2)`

Merge swiftlang#38335

7f0f2ac

fix test

03463ea

FreeBSD cxx stdlib and tests fixes

26dd5c3

michael-yuji force-pushed the mchiu/freebsd branch from c22dacb to 26dd5c3 Compare March 14, 2025 20:00

michael-yuji requested review from j-hui and fahadnayyar as code owners March 14, 2025 20:00

jakepetroules added this to Swift on FreeBSD Mar 18, 2025

jakepetroules moved this to In Progress in Swift on FreeBSD Mar 18, 2025

Arm64 FreeBSD toolchain should use 'aarch64' arch

617a701

michael-yuji requested a review from susmonteiro as a code owner March 24, 2025 22:48

disable fake toolchain test on freebsd

ec41711

tmmvn reviewed May 14, 2025

View reviewed changes

Merge branch 'main' into mchiu/freebsd

9a948a9

michael-yuji requested review from etcwilde, justice-adams-apple, shahmishal and hnrklssn as code owners May 21, 2025 23:29

CodingCarpincho approved these changes May 22, 2025

View reviewed changes

Merge branch 'main' into mchiu/freebsd

8738e72

[FreeBSD] Adding FreeBSD support #77836

Are you sure you want to change the base?

[FreeBSD] Adding FreeBSD support #77836

Conversation

michael-yuji commented Nov 25, 2024

Uh oh!

lin72h commented Nov 25, 2024

Uh oh!

michael-yuji commented Nov 26, 2024

Uh oh!

lin72h commented Nov 26, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

finagolfin commented Nov 26, 2024

Uh oh!

3405691582 commented Nov 30, 2024

Uh oh!

khng300 commented Dec 1, 2024

Uh oh!

michael-yuji commented Dec 2, 2024

Uh oh!

michael-yuji commented Dec 3, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakepetroules commented Feb 12, 2025

Uh oh!

jakepetroules commented Feb 13, 2025

Uh oh!

egorzhdan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!