Repository navigation
Build the rust-std component for embedded targets #49382
Description
Activity
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 binary size range - might be hard to enforce this
- Some kind of QEMU testing for sanity checks
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).
@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.
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.
This is a P-high embedded-WG issue that needs to be fixed to make embedded Rust work on stable.
Targets like
thumbv7m-none-eabineed to use Xargo, which requires nightly, because there's nopre-compiled
corecrate (i.e.rustup target add thumbv7m-none-eabidoesn't work).To fastest way to remove this nightly dependency is to provide a
rust-stdcomponent (pre-compiledcore) for the embedded targets. Then users would be able to use
rustup target thumbv7m-none-eabi; cargo build --target thumbv7m-none-eabifor embedded development.The embedded targets
rustccurrently supports are:thumbv6m-none-eabithumbv7m-none-eabithumbv7em-none-eabithumbv7em-none-eabihfmsp430-none-elfThe Thumb targets have a more stable LLVM backend so we can commit to always building
coreforthat target. The MSP430 backend is slightly less stable so we don't want to block the PR pipeline if
building
corefor the MSP430 target breaks.This issue can be split in two parts:
rust-stdbuilds for the 4 Thumb targets. Gating oncorebuilding for those targets.core/stdbuild fail, and enablerust-stdbuilds for theMSP430 target. We won't gate on
corebuilding for the MSP430 target.cc @alexcrichton who can give more info about how to implement this
cc @pftbest