Add platform docs for FreeBSD.

[asomers]

No description provided.

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[asomers]

cc @tgross35 . Also, perhaps @MikaelUrankar would like to sign up as a second target maintainer?

[ehuss]

r? ehuss

Looks like we have two PRs updating the same thing over at #128546.

Can we combine them? Or I can merge #128546 now, until this is ready?

[workingjubilee]

In the platform support docs, please note that FreeBSD's ports patches i686-unknown-freebsd in a way that introduces incorrect compilations, thus people must use the upstream toolchain instead of a FreeBSD-built toolchain for building for i686-unknown-freebsd without introducing incorrect compilations.

Unless this changes, of course.

[beetrees]

Ideally (since FreeBSD wants to support pre-SSE2 CPUs), instead of FreeBSD ports patching the i686-unknown-freebsd package to be subtly different than upstream, a separate i586-unknown-freebsd target should be introduced (similar to the existing i586-unknown-linux-gnu target for Linux). That way upstream and FreeBSD ports targets can have the same behaviour, and users can pick between "I want to support really old hardware" (i586) and "I want to be able to use floats" (i686), same as they can on other operating systems.

[beetrees]

Also, as far as I can tell, the powerpc64-unknown-freebsd target in upstream Rust supports FreeBSD 12 only as FreeBSD 13+ switched to the ELFv2 ABI, which the FreeBSD port patches the Rust compiler to use. Given that FreeBSD 12 is EOL, the solution seems to be to upstream a cx.target_spec().os == "freebsd" version of the patch (the FreeBSD ports patch currently changes all big-endian PowerPC64 targets to use ELFv2, not just FreeBSD), and just state that powerpc64-unknown-freebsd only supports FreeBSD 13+. The target description also needs to be updated: currently it states "PPC64 FreeBSD (ELFv1 and ELFv2)" which is incorrect as the compiler currently only supports the ELFv1 ABI for the target (and after the patch is upstreamed will only support the ELFv2 ABI for the target).

[MikaelUrankar]

cc @tgross35 . Also, perhaps @MikaelUrankar would like to sign up as a second target maintainer?

Yes, you can put me as a 2nd target maintainer.

[asomers]

@workingjubilee @beetrees the decision to build lang/rust without SSE support was made in 2017, before any of the linked LLVM issues. I'll start a discussion about revisiting it. I'll inquire about the ELFv1/ELFv2 issue too.

[rust-log-analyzer]

The job x86_64-gnu-llvm-17 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

------
 > importing cache manifest from ghcr.io/rust-lang/rust-ci-cache:20d3b4d4a2629cbf7865cdbf92fe47512a7c96658c24253a045ff38e8075cd7fb37ca6fcadfa6e6d093333943ad24f6fc4f163ec5b74fd940de9d5bb03eb4d3b:
------
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-17]
---
sccache: Starting the server...
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-17', '--enable-llvm-link-shared', '--set', 'rust.thin-lto-import-instr-limit=10', '--set', 'change-id=99999999', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--set', 'rust.lld=false', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--enable-new-symbol-mangling']
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-17/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.thin-lto-import-instr-limit := 10
configure: change-id            := 99999999
---
  Downloaded boml v0.3.1
   Compiling boml v0.3.1
   Compiling y v0.1.0 (/checkout/compiler/rustc_codegen_gcc/build_system)
    Finished `release` profile [optimized] target(s) in 3.83s
     Running `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-codegen/x86_64-unknown-linux-gnu/release/y test --use-system-gcc --use-backend gcc --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools/cg_gcc --release --mini-tests --std-tests`
Using system GCC
[BUILD] example
[AOT] mini_core_hello_world
/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools/cg_gcc/mini_core_hello_world
abc
---
##[group]Building stage0 tool linkchecker (x86_64-unknown-linux-gnu)
    Finished `release` profile [optimized] target(s) in 0.13s
##[endgroup]
##[group]Testing stage0 Linkcheck (x86_64-unknown-linux-gnu)
rustc/platform-support.html:263: broken link - `rustc/platform-support/freebsd.html`
rustc/platform-support.html:324: broken link - `rustc/platform-support/freebsd.html`
rustc/platform-support.html:403: broken link - `rustc/platform-support/freebsd.html`
rustc/platform-support.html:421: broken link - `rustc/platform-support/freebsd.html`
rustc/platform-support.html:427: broken link - `rustc/platform-support/freebsd.html`
rustc/platform-support.html:484: broken link - `rustc/platform-support/freebsd.html`
rustc/platform-support.html:485: broken link - `rustc/platform-support/freebsd.html`
rustc/platform-support.html:486: broken link - `rustc/platform-support/freebsd.html`
rustc/print.html:9606: broken link - `rustc/platform-support/freebsd.html`
rustc/print.html:9667: broken link - `rustc/platform-support/freebsd.html`
rustc/print.html:9746: broken link - `rustc/platform-support/freebsd.html`
rustc/print.html:9764: broken link - `rustc/platform-support/freebsd.html`
rustc/print.html:9770: broken link - `rustc/platform-support/freebsd.html`
rustc/print.html:9827: broken link - `rustc/platform-support/freebsd.html`
rustc/print.html:9828: broken link - `rustc/platform-support/freebsd.html`
rustc/print.html:9829: broken link - `rustc/platform-support/freebsd.html`
number of HTML files scanned: 43611
number of HTML redirects found: 13713
number of links checked: 3198524
number of links ignored due to external: 78499
number of links ignored due to external: 78499
number of links ignored due to exceptions: 17
number of intra doc links ignored: 8
errors found: 16
found some broken links
Command has failed. Rerun with -v to see more details.
  local time: Wed Aug 21 00:01:01 UTC 2024
  network time: Wed, 21 Aug 2024 00:01:01 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

[workingjubilee]

Ideally (since FreeBSD wants to support pre-SSE2 CPUs)

I am not entirely sure they do? I have been informed contrariwise, i.e. that FreeBSD is only interested in Pentium 4 or later equivalents. Naturally, that might have been decided many years after the 2017 decision!

Of course, if two targets settles the matter for FreeBSD, that is fine by me, and if a documentation change is preferred, that is also fine by me. I do not mean to be obstructive, I merely want the matter to be clear for everyone involved.

[beetrees]

I was inferring "since FreeBSD wants to support pre-SSE2 CPUs" from the FreeBSD i386 platform page, which states "FreeBSD/i386 should support any CPU compatible with the Intel Pentium Pro / Pentium II (i686) or better" (it's quite possible that the platform page is out of date though).

It's worth noting that the FreeBSD 14.1 release notes state that 32-bit x86 platform support will be dropped from FreeBSD 15 onwards, while support for running 32-bit binaries on 64-bit x86 will remain for at least FreeBSD 15 and 16. Given that all 64-bit x86 CPUs support SSE2, there will definitely be no need for non-SSE2 CPU support after FreeBSD 14 reaches EOL (currently expected to be in November 2028).

[emaste]

maybe "the FreeBSD ports tree"

[beetrees]

#120869 appears relevant to this PR as it bumps the minimum supported FreeBSD version.

[bors]

☔ The latest upstream changes (presumably #120869) made this pull request unmergeable. Please resolve the merge conflicts.

[ehuss]

Just FYI, you'll need to add the link to SUMMARY.md. Also, I'd suggest fixing the target definitions in
compiler/rustc_target/src/spec/targets if those are indeed incorrect. See #128546 for examples of these changes.

[workingjubilee]

@ehuss I would rather not deliberately introduce miscompilations into existing tier 2 targets that currently have none, whether or not ports has decided to make their target unsound.

[ehuss]

@workingjubilee Sorry, I'm not following. Are you asking that the change requested above be resolved? I'm not the author, so I wouldn't be the one making that change. As the reviewer, I won't merge until it is resolved.

Or maybe you intended to tag one of the other commenters here? Sorry, I'm confused. 😕

[workingjubilee]

@ehuss I am saying that the resolution can include ports fixing its target definition to not make Rust code unsound, i.e. by ceasing to apply their patch, rather than it being "fixed" here by making the target unsound for our toolchain as well.

Unless that is what you meant, in which case it was just unclear to me, apologies.

[asomers]

A change is underway to reenable SSE on i386 by default: https://reviews.freebsd.org/D47227

[ehuss]

@rustbot author

[Dylan-DPC]

@asomers any updates on this? thanks

[asomers]

@asomers any updates on this? thanks

I expect to merge that change, reenabling SSE2 on i386, by EoD on Saturday.