Build the rust-std component for embedded targets

[japaric]

This is a P-high embedded-WG issue that needs to be fixed to make embedded Rust work on stable.

Targets like thumbv7m-none-eabi need to use Xargo, which requires nightly, because there's no
pre-compiled core crate (i.e. rustup target add thumbv7m-none-eabi doesn't work).

To fastest way to remove this nightly dependency is to provide a rust-std component (pre-compiled
core) for the embedded targets. Then users would be able to use rustup target thumbv7m-none-eabi; cargo build --target thumbv7m-none-eabi for embedded development.

The embedded targets rustc currently supports are:

• thumbv6m-none-eabi
• thumbv7m-none-eabi
• thumbv7em-none-eabi
• thumbv7em-none-eabihf
• msp430-none-elf

The Thumb targets have a more stable LLVM backend so we can commit to always building core for
that target. The MSP430 backend is slightly less stable so we don't want to block the PR pipeline if
building core for the MSP430 target breaks.

This issue can be split in two parts:

• Enabling rust-std builds for the 4 Thumb targets. Gating on core building for those targets.
• Create some mechanism to let core / std build fail, and enable rust-std builds for the
  MSP430 target. We won't gate on core building for the MSP430 target.

cc @alexcrichton who can give more info about how to implement this
cc @pftbest

[oli-obk]

cc @phil-opp

[jamesmunns]

Part of this is also integrating CI for embedded targets, especially cortex_m/thumb targets
Need to define what needs to be tested, including possibly:

• https://github.com/japaric/stable-embedded-rust builds, with examples
• Some kind of static analysis
  • Some kind of binary size range - might be hard to enforce this
    • Alternative is annotating certain items with a new "Don't unroll attribute" @nagisa
    • Track it in size graphs, but maybe not gate on it
    • Emit some kind of warning or "Shout out"/"Heads Up", but don't gate the build
    • Consider using "optimize for size" for regression testing, since that is the "last resort"
  • Some kind of symbol checking
• Some kind of QEMU testing for sanity checks

[whitequark]

Consider using "optimize for size" for regression testing, since that is the "last resort"

Are you sure it's "last resort"? IME nearly all embedded code is built with -Os (which is based on -O2 anyway).

[jamesmunns]

@whitequark sorry, "last resort" wasn't a very descriptive phrase. It was meant as a "last resort for someone trying to reduce their code size due to going over their target size limit when using cargo run --release".

In context, we were talking about making a regression test that would gate Rust releases if the size increased dramatically for embedded targets. Initially we were planning to use a --release build for this, but there was pushback because of how LLVM can change version to version based on how aggressively it tries to unroll/inline. There was more support for basing this regression test on -Os or -O2, since that should have more consistent "small code size" behavior, and any large increases in binary size are likely due to some other issue.

[japaric]

PR #49563 build rust-std for ARM Cortex-M.

[necrose99]

rustup target add aarch64-pc-windows-msvc
rustup target add armv7-pc-windows-msvc
rustup target add aarch64-pc-windows-gnu
rustup target add armv7-pc-windows-gnu

rpi-3 windows 10 , rock64/pine64 windows 10 embedded...

Windows Server ported to Qualcomm's ARM server chip.

[japaric]

This has been done for the thumb targets and there's an open PR for msp430 so I'm going to close this issue in favor of that open PR.

[japaric]

there's an open PR for msp430

The PR is #51250