lang/rust: Add freestanding targets for FreeBSD tier 1 archs

[guest-ayrton]

Summary

Adds an option to build freestanding targets suitable for compiling kernel
drivers for the current FreeBSD tier 1 archs (aarch64-unknown-none-softfloat and
x86_64-unknown-none). The new option is on by default to simplify the process of
testing out rust KPI bindings. Note the new option does not affect whether rustc
uses the bundled lld since these targets are just intended for building static
archives and rlibs.

Test Plan

I tested by building and installing rust with the FREESTANDING option on ARM64
and checked that the build instructions for my rust bindings worked as expected.

[guest-ayrton]

One thing I forgot to note in the commit message is that this option is mutually exclusive with the DOCS options[1]. I'm not sure whether to add a .error if both are set or to just disable the freestanding option and print a .warning or .info message.

Also it'd be great to have this an on by default to make it easier on developers wanting to try out rust in the kernel, especially since rustup (the standard rust toolchain installer) currently doesn't support FreeBSD on aarch64 so the only alternative there is building rustc from source. The new targets also only build libcore.rlib, liballoc.rlib and libcompiler_builtins.rlib so they should not use significant disk space.

[1] AFAICT setting docs=true in the config.toml at the root of rustc-src will attempt to run rustdoc on std even for targets that only support core/alloc and set no-std=true (which targets containing -none set by default). I tested a few different ways of adding the new targets, but ultimately I think supporting both options would require reworking the do-configure target to generate two config.tomls.

[asomers]

Does this option cause the port to build both the aarch64 and x86_64 freestanding targets, regardless of the host architecture? Why not build freestanding targets only for the host arch?

Also, do you think the docs problem is a bug upstream?

[mikael]

Can you sort the options please?

[guest-ayrton]

Hello! I haven't forgotten about this, I've just been fleshing out the code using it. At some point I realized that it's more appropriate to generate the artifacts this change adds (libcore.rlib and libcompiler-builtins.rlib for the kernel arch) as part of each kernel build using the sources in the rust compiler repo. My bindings are pretty much at a state where developers can try it out (and I have a virtio-snd driver demo anyone can already run in QEMU), but it would be nice to have a better solution for getting a rust compiler when building on FreeBSD hosts before announcing it on the mailing lists.

Integrating rust does require a "nightly" compiler (mainly since the makefiles build libcore) like I explain here[1], but the specific version doesn't matter as long as its new enough to support edition 2024. My instructions currently say just do pkg install rust-nightly (giving a developer whatever version that week's rust-nightly package is) and the KPI crate and demos should build because they intentionally avoid unstable features and APIs. The potential problem is that if a developer writes a driver using a libcore API stabilized in version X, another developer on version X - 1 might not be able to build it. Also I'd really like to avoid saying "just build on X - 1 with #![feature(the_API_stabilized_in_X)]" because that will make bumping the toolchain very painful. @mikael do you have a preference on how to add a package for rust-nightly (version 1.88.0 nightly-2025-05-01 or newer) that has its version pinned? It could be x86-only if that makes it easier because cross compiling for aarch64 is trivial and ironically rustup on linux/MacOS makes it way easier to build for either target with any version.

[1] https://github.com/ayrtonm/freebsd-kpi-rs?tab=readme-ov-file#installing-rust-and-build-tools