[aliiupeng]

Adds 3 Vega OS targets: aarch64-vega-linux-gnu, armv7-vega-linux-gnueabihf and x86_64-vega-linux-gnu. They are essentially the -unknown-linux-gnu targets with target_vendor = vega, the in-tree LLVM libunwind by default (Vega OS has no libgcc_s), and a Cortex-A7/NEON baseline on armv7.

Vega OS is Linux-based OS developed by Amazon which is used on Fire TV, Echo and other Amazon devices.
https://developer.amazon.com/docs/vega/vega

Thousands of 3rd party vega developers build Vega apps with the public Vega SDK, and the SDK will ship Rust support built on these targets.

How they differ from *-unknown-linux-gnu*

• We kept the target_os and target_env unchanged as "linux" and "gnu". But we changed the target_vendor to "vega".
• for armv7, a Cortex-A7 baseline with VFPv4 and NEON, which matches what Vega userspace is built for.
• Because Vega doesn't ship shared libgcc_s for apps, std links LLVM libunwind statically instead. bootstrap defaults llvm-libunwind to in-tree for these targes, like Fuchsia and Hexagon Linux. When std is build without its llvm-libunwind(for example with -Zbuild-std), library/unwind links the Vega sysroot's libunwind.a statically, similar to Hexagon and OHOS. It is static on purpose because system-llvm-libunwind would link the shared library, which apps can't use.

Why separate targets

• Code can detect Vega with cfg(target_vendor = "vega") in any build
• The unwinder. Which unwinder std links is fixed when std is compiled, by target. The *-unknown-linux-gnu std links libgcc_s.so.1, which Vega doesn't provide to apps: the SDK sysroot has no libgcc_s, and the OS doesn't export it to apps. So the upstream *-unknown-linux-gnu std can't be used for Vega apps. Today the Vega SDK has to rebuild std itself with llvm-libunwind, plus empty libgcc link stubs. With a Vega target, std picks LLVM libunwind automatically (bootstrap, -Zbuild-std, and a future rustup-shipped std), with no unstable flags. Otherwise it needs nightly-only -Zbuild-std-features=llvm-libunwind or a custom std. Precedent: OHOS and Hexagon Linux also differ from their base in which unwinder std links.
• On a linux x86_64 host, x86_64-unknown-linux-gnu is both the host and the target, so Cargo applies the Vega link setttings to build scripts and proc marcros too. A different name avoids this.
• The *-oe-linux-gnu targets default to the OpenEmbedded GCC driver and libgcc_s, so they don't fit. Also it keeps unknown target_vendor and use the generic armv7 baseline.

Testing

• Tidy pass.
• ./x build --stage 1 library succeeds for all three targets, using clang 19 and a Vega sysroot.
• A test binary that panics, unwinds through Drop into catch_unwind and spawns a thread
  runs correctly on x86_64 through the sysroot's loader, and on aarch64 and armv7 under
  qemu-user with the Vega sysroot. It depends only on libc.so.6 and the dynamic loader.
• A crate with C code built through the cc crate builds on all three targets.

LLM disclosure

I wrote the doc and proposal, and used LLM to validate and reviewed them for accuracy. The LLM write the commit message but I rewrote it later. The code is drafted by LLM and I reviewed and validated the changes.

r? compiler

Tier 3 target policy

• 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.)

@aliiupeng and @altrieu-amazon, both on the Vega SDK team at Amazon. Our manager has
approved maintaining these targets as an ongoing team responsibility: answering issues,
fixing build breaks and upstreaming fixes. If either of us moves on, the team will name a
replacement and update the list.

• 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.
  • 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.
  • If possible, use only letters, numbers, dashes and underscores for the name.
    Periods (.) are known to cause issues in Cargo.

The names follow <arch>-<vendor>-linux-<env>. Each one keeps the arch and env of the
matching upstream target (aarch64-unknown-linux-gnu, armv7-unknown-linux-gnueabihf,
x86_64-unknown-linux-gnu) and changes only the vendor, like x86_64-unikraft-linux-musl
and mips64-openwrt-linux-musl.

The names use only letters, digits, dashes and underscores.

• 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.
  • Anything added to the Rust repository must be under the standard Rust
    license (MIT OR Apache-2.0).
  • 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.
  • 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.
  • "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.

Everything added is under MIT OR Apache-2.0, and the PR adds no dependencies.

Building and linking for these targets needs only FOSS components: clang and lld, glibc,
and the LLVM runtimes (libunwind, libc++, compiler-rt). The Vega SDK is a free download and
a convenient way to get a matching clang and sysroot, but it is not required.

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

Understood. None of the maintainers is a member of an approving Rust team.

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

std is fully supported. These are glibc Linux targets (target_os = "linux",target_env = "gnu"), so they use the same std code paths as *-unknown-linux-gnu*. The only std-side difference is the unwinder link in library/unwind.

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

src/doc/rustc/src/platform-support/vega-linux-gnu.md covers building the targets (with bootstrap or build-std), linking, running binaries (natively on x86_64 Linux, under qemu-user for aarch64 and armv7, on the Vega Virtual Device, or on Fire TV devices), and building C code.

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

Understood.

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

The target specs are new files. Shared code changes in two places, and both apply only to Vega:

• bootstrap's llvm-libunwind default, which matches only -vega-linux- target names;
• the link rules in library/unwind/src/lib.rs, gated on target_vendor = "vega". The existing gcc_s and system-llvm-libunwind rules exclude Vega, so other Linux targets link exactly as before.

target_vendor = "vega" adds a new value but changes no existing cfg: no std, core, compiler, bootstrap or libc code checks target_vendor = "unknown". The check-cfg UI test expectations are updated for the new vendor value.

• Tier 3 targets must be able to produce assembly using at least one of
  rustc's supported backends from any host target. (Having support in a fork
  of the backend is not sufficient, it must be upstream.)

They use the upstream LLVM AArch64, ARM and X86 backends. The targets-elf assembly test covers all three.

This PR is drafted with help of LLM. I reviewed and validated it.

[rustbot]

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

These commits modify compiler targets.
(See the Target Tier Policy.)

[rustbot]

Error: Failed to set assignee to [AGREED: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[jieyouxu]

r? compiler_leads

[weihanglo]

FWIW, I've helped review this a bit, and so has @Mark-Simulacrum, but clearly I am not on compiler team, and we have conflict of interest.

View changes since this review

[rust-bors]

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