bjoernager/rust
bjoernager/rust
1
Fork 0
Code Activity

Rollup merge of #108795 - thomcc:x86_64h-target, r=wesleywiser

Browse source 
Add support for the x86_64h-apple-darwin target

See https://github.com/rust-lang/compiler-team/issues/599 for MCP.

r? compiler-team

CC `@BlackHoleFox` who recently overhauled the apple target code in `rustc-target`.

## Target Support Checklist

> - A tier 3 target must have a designated developer or developers (the "target
>   maintainers") on record to be CCed when issues arise regarding the target.
>   (The mechanism to track and CC such developers may evolve over time.)

I'm the designated developer.

> - Targets must use naming consistent with any existing targets; for instance, a
>   target for the same CPU or OS as an existing Rust target should use the same
>   name for that CPU or OS. Targets should normally use the same names and
>   naming conventions as used elsewhere in the broader ecosystem beyond Rust
>   (such as in other toolchains), unless they have a very good reason to
>   diverge. Changing the name of a target can be highly disruptive, especially
>   once the target reaches a higher tier, so getting the name right is important
>   even for a tier 3 target.

This uses the same naming conventions used for the other macOS targets (`-apple-darwin`), combined with the convention used by LLVM for the `x86_64h` targets. LLVM's convention matches the architecture name used when invoking various tools such as `lipo`, `arch`, and (IMO) there's not really a compelling reason to depart from it.

> - Target names should not introduce undue confusion or ambiguity unless
>   absolutely necessary to maintain ecosystem compatibility. For example, if
>   the name of the target makes people extremely likely to form incorrect
>   beliefs about what it targets, the name should be changed or augmented to
>   disambiguate it.

I don't think this is especially likely, although I suppose someone could mistake it for `x86_64-apple-darwin`.

> - If possible, use only letters, numbers, dashes and underscores for the name.
>   Periods (`.`) are known to cause issues in Cargo.

👍

> - Tier 3 targets may have unusual requirements to build or use, but must not
>   create legal issues or impose onerous legal terms for the Rust project or for
>   Rust developers or users.
>   - The target must not introduce license incompatibilities.

It does not.

> - Anything added to the Rust repository must be under the standard Rust
>   license (`MIT OR Apache-2.0`).

It is.

> - The target must not cause the Rust tools or libraries built for any other
>   host (even when supporting cross-compilation to the target) to depend
>   on any new dependency less permissive than the Rust licensing policy. This
>   applies whether the dependency is a Rust crate that would require adding
>   new license exceptions (as specified by the `tidy` tool in the
>   rust-lang/rust repository), or whether the dependency is a native library
>   or binary. In other words, the introduction of the target must not cause a
>   user installing or running a version of Rust or the Rust tools to be
>   subject to any new license requirements.

There are no new dependencies that don't also apply to `x86_64-apple-darwin`.

> - Compiling, linking, and emitting functional binaries, libraries, or other
>   code for the target (whether hosted on the target itself or cross-compiling
>   from another target) must not depend on proprietary (non-FOSS) libraries.
>   Host tools built for the target itself may depend on the ordinary runtime
>   libraries supplied by the platform and commonly used by other applications
>   built for the target, but those libraries must not be required for code
>   generation for the target; cross-compilation to the target must not require
>   such libraries at all. For instance, `rustc` built for the target may
>   depend on a common proprietary C runtime library or console output library,
>   but must not depend on a proprietary code generation library or code
>   optimization library. Rust's license permits such combinations, but the
>   Rust project has no interest in maintaining such combinations within the
>   scope of Rust itself, even at tier 3.

This has the same requirements as the other macOS targets (e.g. `x86_64-apple-darwin` and similar).

> - "onerous" here is an intentionally subjective term. At a minimum, "onerous"
>   legal/licensing terms include but are *not* limited to: non-disclosure
>   requirements, non-compete requirements, contributor license agreements
>   (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
>   requirements conditional on the employer or employment of any particular
>   Rust developers, revocable terms, any requirements that create liability
>   for the Rust project or its developers or users, or any requirements that
>   adversely affect the livelihood or prospects of the Rust project or its
>   developers or users.

No change here.

> - Neither this policy nor any decisions made regarding targets shall create any
>   binding agreement or estoppel by any party. If any member of an approving
>   Rust team serves as one of the maintainers of a target, or has any legal or
>   employment requirement (explicit or implicit) that might affect their
>   decisions regarding a target, they must recuse themselves from any approval
>   decisions regarding the target's tier status, though they may otherwise
>   participate in discussions.

👍

> - This requirement does not prevent part or all of this policy from being
>   cited in an explicit contract or work agreement (e.g. to implement or
>   maintain support for a target). This requirement exists to ensure that a
>   developer or team responsible for reviewing and approving a target does not
>   face any legal threats or obligations that would prevent them from freely
>   exercising their judgment in such approval, even if such judgment involves
>   subjective matters or goes beyond the letter of these requirements.

👍

> - Tier 3 targets should attempt to implement as much of the standard libraries
>   as possible and appropriate (`core` for most targets, `alloc` for targets
>   that can support dynamic memory allocation, `std` for targets with an
>   operating system or equivalent layer of system-provided functionality), but
>   may leave some code unimplemented (either unavailable or stubbed out as
>   appropriate), whether because the target makes it impossible to implement or
>   challenging to implement. The authors of pull requests are not obligated to
>   avoid calling any portions of the standard library on the basis of a tier 3
>   target not implementing those portions.

The standard library tests seem to pass.

> - The target must provide documentation for the Rust community explaining how
>   to build for the target, using cross-compilation if possible. If the target
>   supports running binaries, or running tests (even if they do not pass), the
>   documentation must explain how to run such binaries or tests for the target,
>   using emulation if possible or dedicated hardware if necessary.

Documentation is provided.

> - Tier 3 targets must not impose burden on the authors of pull requests, or
>   other developers in the community, to maintain the target. In particular,
>   do not post comments (automated or manual) on a PR that derail or suggest a
>   block on the PR based on a tier 3 target. Do not send automated messages or
>   notifications (via any medium, including via ``@`)` to a PR author or others
>   involved with a PR regarding a tier 3 target, unless they have opted into
>   such messages.

Noted. This target is nearly identical to `x86_64-apple-darwin`, so this is
unlikely to cause issues anyway.

> - Backlinks such as those generated by the issue/PR tracker when linking to
>   an issue or PR are not considered a violation of this policy, within
>   reason. However, such messages (even on a separate repository) must not
>   generate notifications to anyone involved with a PR who has not requested
>   such notifications.

👍

> - Patches adding or updating tier 3 targets must not break any existing tier 2
>   or tier 1 target, and must not knowingly break another tier 3 target without
>   approval of either the compiler team or the maintainers of the other tier 3
>   target.
>   - In particular, this may come up when working on closely related targets,
>     such as variations of the same architecture with different features. Avoid
>     introducing unconditional uses of features that another variation of the
>     target may not have; use conditional compilation or runtime detection, as
>     appropriate, to let each target run code supported by that target.

👍
This commit is contained in:
Matthias Krüger 2023-04-20 17:59:53 +02:00 • committed by GitHub
commit 7dc211f5ce
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
6 changed files with 120 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

21
compiler/rustc_target/src/spec/apple_base.rs
View file

@ -19,6 +19,7 @@ pub enum Arch {
I386,
I686,
X86_64,
X86_64h,
X86_64_sim,
X86_64_macabi,
Arm64_macabi,
@ -36,6 +37,7 @@ impl Arch {
I386 => "i386",
I686 => "i686",
X86_64 | X86_64_sim | X86_64_macabi => "x86_64",
X86_64h => "x86_64h",
}
}
@ -44,13 +46,13 @@ impl Arch {
Armv7 | Armv7k | Armv7s => "arm",
Arm64 | Arm64_32 | Arm64_macabi | Arm64_sim => "aarch64",
I386 | I686 => "x86",
X86_64 | X86_64_sim | X86_64_macabi => "x86_64",
X86_64 | X86_64_sim | X86_64_macabi | X86_64h => "x86_64",
})
}
fn target_abi(self) -> &'static str {
match self {
Armv7 | Armv7k | Armv7s | Arm64 | Arm64_32 | I386 | I686 | X86_64 => "",
Armv7 | Armv7k | Armv7s | Arm64 | Arm64_32 | I386 | I686 | X86_64 | X86_64h => "",
X86_64_macabi | Arm64_macabi => "macabi",
// x86_64-apple-ios is a simulator target, even though it isn't
// declared that way in the target like the other ones...
@ -67,6 +69,10 @@ impl Arch {
Arm64_32 => "apple-s4",
I386 | I686 => "yonah",
X86_64 | X86_64_sim => "core2",
// Note: `core-avx2` is slightly more advanced than `x86_64h`, see
// comments (and disabled features) in `x86_64h_apple_darwin` for
// details.
X86_64h => "core-avx2",
X86_64_macabi => "core2",
Arm64_macabi => "apple-a12",
Arm64_sim => "apple-a12",
@ -182,8 +188,13 @@ fn deployment_target(var_name: &str) -> Option<(u32, u32)> {
}
fn macos_default_deployment_target(arch: Arch) -> (u32, u32) {
// Note: Arm64_sim is not included since macOS has no simulator.
if matches!(arch, Arm64 | Arm64_macabi) { (11, 0) } else { (10, 7) }
match arch {
// Note: Arm64_sim is not included since macOS has no simulator.
Arm64 | Arm64_macabi => (11, 0),
// x86_64h-apple-darwin only supports macOS 10.8 and later
X86_64h => (10, 8),
_ => (10, 7),
}
}
fn macos_deployment_target(arch: Arch) -> (u32, u32) {
@ -227,7 +238,7 @@ fn link_env_remove(arch: Arch, os: &'static str) -> StaticCow<[StaticCow<str>]>
// of the linking environment that's wrong and reversed.
match arch {
Armv7 | Armv7k | Armv7s | Arm64 | Arm64_32 | I386 | I686 | X86_64 | X86_64_sim
| Arm64_sim => {
| X86_64h | Arm64_sim => {
cvs!["MACOSX_DEPLOYMENT_TARGET"]
}
X86_64_macabi | Arm64_macabi => cvs!["IPHONEOS_DEPLOYMENT_TARGET"],

1
compiler/rustc_target/src/spec/mod.rs
View file

@ -1112,6 +1112,7 @@ supported_targets! {
("aarch64-apple-darwin", aarch64_apple_darwin),
("x86_64-apple-darwin", x86_64_apple_darwin),
("x86_64h-apple-darwin", x86_64h_apple_darwin),
("i686-apple-darwin", i686_apple_darwin),
// FIXME(#106649): Remove aarch64-fuchsia in favor of aarch64-unknown-fuchsia

44
compiler/rustc_target/src/spec/x86_64h_apple_darwin.rs Normal file
View file

@ -0,0 +1,44 @@
use super::apple_base::{macos_llvm_target, opts, Arch};
use crate::spec::{Cc, FramePointer, LinkerFlavor, Lld, SanitizerSet};
use crate::spec::{StackProbeType, Target, TargetOptions};
pub fn target() -> Target {
let arch = Arch::X86_64h;
let mut base = opts("macos", arch);
base.max_atomic_width = Some(128);
base.frame_pointer = FramePointer::Always;
base.add_pre_link_args(LinkerFlavor::Darwin(Cc::Yes, Lld::No), &["-m64"]);
base.stack_probes = StackProbeType::X86;
base.supported_sanitizers =
SanitizerSet::ADDRESS | SanitizerSet::CFI | SanitizerSet::LEAK | SanitizerSet::THREAD;
// x86_64h is core2-avx without a few of the features which would otherwise
// be guaranteed, so we need to disable those. This imitates clang's logic:
// - https://github.com/llvm/llvm-project/blob/bd1f7c417/clang/lib/Driver/ToolChains/Arch/X86.cpp#L77-L78
// - https://github.com/llvm/llvm-project/blob/bd1f7c417/clang/lib/Driver/ToolChains/Arch/X86.cpp#L133-L141
//
// FIXME: Sadly, turning these off here disables them in such a way that they
// aren't re-enabled by `-Ctarget-cpu=native` (on a machine that has them).
// It would be nice if this were not the case, but fixing it seems tricky
// (and given that the main use-case for this target is for use in universal
// binaries, probably not that important).
base.features = "-rdrnd,-aes,-pclmul,-rtm,-fsgsbase".into();
// Double-check that the `cpu` is what we expect (if it's not the list above
// may need updating).
assert_eq!(
base.cpu, "core-avx2",
"you need to adjust the feature list in x86_64h-apple-darwin if you change this",
);
Target {
// Clang automatically chooses a more specific target based on
// MACOSX_DEPLOYMENT_TARGET. To enable cross-language LTO to work
// correctly, we do too.
llvm_target: macos_llvm_target(arch).into(),
pointer_width: 64,
data_layout: "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
.into(),
arch: arch.target_arch(),
options: TargetOptions { mcount: "\u{1}mcount".into(), ..base },
}
}