[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.

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

To rathole a bit, what does FreeBSD call its libc, if anything?

It doesn't have a separate name, t's just the FreeBSD libc.

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

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

FreeBSD has separate notions of MACHINE and MACHINE_ARCH and we ended up with arm64 as the MACHINE and aarch64 as the MACHINE_ARCH. The code isn't going to need to check for both; if what it's fetching is the MACHINE_ARCH it will remain aarch64.

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.

jrtc27 · 2025-05-29T18:13:09Z

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


This comment implies that FreeBSD 15 changed libc++ ABI to support this, but that's not true, it still hasn't happened, and it's not clear if or when it will

NB: Upstream libc++ still has the patch to break ABI and support this for FreeBSD >= 14 (not > 14 as this implies), but the vendored copy in FreeBSD used to build /usr/lib/libc++.so.1 is patched to keep the old ABI for all versions.

jrtc27 · 2025-05-29T18:13:28Z

include/swift/SILOptimizer/Differentiation/DifferentiationInvoker.h

@@ -71,10 +71,17 @@ struct DifferentiationInvoker {

    /// The parent `apply` instruction and the witness associated with the
    /// `IndirectDifferentiation` case.
-    std::pair<ApplyInst *, SILDifferentiabilityWitness *>
-        indirectDifferentiation;
+    /// Note: This used to be a std::pair, but on FreeBSD <= 14, libc++ is


jrtc27 · 2025-05-29T18:17:38Z

stdlib/public/core/CTypes.swift

@@ -116,6 +116,8 @@ public typealias CLongDouble = Double
 #elseif os(FreeBSD)
 #if arch(x86_64) || arch(i386)
 public typealias CLongDouble = Float80
+#elseif arch(arm64)
+public typealias CLongDouble = Double


Isn't it Float128 (also for OpenBSD)? I note that there are various comments above about Float128 not being supported, so perhaps this should be omitted for arm64 on *BSD?

jrtc27 · 2025-05-29T18:18:02Z

stdlib/public/runtime/CMakeLists.txt

@@ -93,7 +93,8 @@ set(swift_runtime_backtracing_sources
  Backtrace.cpp
  BacktraceUtils.cpp
  CrashHandlerMacOS.cpp
-  CrashHandlerLinux.cpp)
+  CrashHandlerLinux.cpp
+)


Probably shouldn't be reformatted if you're not otherwise touching the file?

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

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

jrtc27 reviewed May 29, 2025

View reviewed changes

[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!

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!

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!

Uh oh!

CodingCarpincho commented May 29, 2025

Uh oh!

3405691582 commented May 29, 2025

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!

Uh oh!