Create a list of compiler/cargo features desired to be stabilized/implemented for embedded use cases

[manczak-ifx]

As discussed in the Unconf Rustweek2025 a list of features for the compiler that are necessary for embedded use cases (e.g. security extensions) and cargo features (e.g. support of multiple runners, workspaces with multiple targets)

[BartMassey]

We haven't made any progress. Should probably discuss in an REWG meeting soon.

[jamesmunns]

Throwing "stabilize build-std capabilities" onto the list!

[BartMassey]

Right now it's hard to make Cargo understand a crate that needs to be compiled differently for different platforms. Each platform may require its own target and also have platform-specific cfg in the code. There is currently no great way that I am aware of to provide a platform feature that (a) must be set to proceed and (b) selects both the target details and a set of features. I only know of hacky workarounds.

I don't know exactly what I want, but I'm putting this in as a placeholder in case someone is inspired.

###Examples

• The nrf-rs and microbit projects use a common lib crate and separate per-platform crates in a workspace. This works, but makes the codebase harder to navigate and makes it harder to propagate fixes and enhancements from one platform to other platforms. It also takes advantage of the fact that all platform crates have the same target: I don't think it would work if different targets were required.

• The flamingos project uses per-platform features, and then does a compile-time check in the crate source that one of the features is enabled. We would like to use a per-platform target-cpu for the project, but this is currently done by editing .cargo/config.toml at build time since we know of no better way to do this.

[BartMassey]

I know it's already a work in progress, but it's important for embedded use cases to make all the math functions for both integer and floating point const. Sometimes it is necessary to do compile-time math for a target that couldn't do it at runtime; in any case, it is important to minimize the runtime code size.

Right now I'm doing this in my no_std crate by doing the compile-time math in build.rs and include!()-ing the result in the target, but this is not ideal: keytones. In particular, it would be nice to be able to not pre-compute everything and instead lazily produce values from a const function when needed.

[romancardenas]

I would love to have a mechanism to let proc macro crates know the target arch of the main compilation. This is especially useful in embedded development. For example, in riscv-rt, we can use the #[riscv_rt::core_interrupt] macro. This function includes a few lines of assembly for the interrupt trap. However, the assembly must be different depending on whether the target architecture is RV32 or RV64.

Currently, we use custom environment variables to do the trick. However, it would be way easier to have an environment variable with the "main" target architecture so we can do more complex checks. without needing to customize build.rs scripts.

[rursprung]

i think quite a few things have already been mentioned here: #835 (comment)

[BartMassey]

That's really useful, thanks! Not sure how we could merge this stuff in: anybody know a Github trick?

[sirhcel]

I would love to be able to get stack size from a stable toolchain. I was looking into a microcontroller application which ran low on (stack) memory and therefor tried to get this information. cargo-callstack failed to build the application with a current nightly toolchain and the recipe from emit-stack-sizes from the Rust Unstable Book gave me no stack size information in the generated binary.

[manczak-ifx]

Common Datapath Extension

Link: https://developer.arm.com/documentation/ka001501/latest/

Currently the CDE compiler flag generates a warning as follows:
rustc --create-type lib main.rs --target thumbv8m.main-none-eabi -Ctarget-feature=+cdecp4

No RFC or compiler issue open about it.

[manczak-ifx]

Stack protector

Link: https://developer.arm.com/documentation/dui0774/l/Compiler-Command-line-Options/-fstack-protector---fstack-protector-all---fstack-protector-strong---fno-stack-protector

Current Limitation: see github issue

Github Issue: rust-lang/rust#114903

[manczak-ifx]

ARM TrustZone for Cortex-M

Link: https://developer.arm.com/documentation/100690/latest/

Stabilization of the support for TrustZone.

Github Issue: rust-lang/rust#81391 and rust-lang/rust#75835 **

Other Information:

Rust tools: https://github.com/tweedegolf/trustzone-m-tools

Blog Post: https://tweedegolf.nl/en/blog/85/trustzone-trials-tribulations

[manczak-ifx]

Simplify generics with type alias impl trait

Managing complex type signatures in embedded systems can be cumbersome. type_alias_impl_trait allows users to abstract these generics behind impl Trait, improving code readability and usability.

Use-case:
Simplifies APIs in embedded systems by hiding complex generics, making code easier to read and maintain.

GitHub issue:
rust-lang/rust#63063

[manczak-ifx]

Support ptr_metadata for efficient dyn Trait handling

The ptr_metadata feature enables splitting wide pointers into thin pointers and metadata. This improves the usability of dyn Trait in memory-constrained, heapless environments.

Use-case:
Supports heapless designs by enabling compact and efficient handling of dynamic trait objects.

GitHub issue:
rust-lang/rust#81513

[manczak-ifx]

Improve pin ergonomics for embedded drivers

pin_ergonomics simplifies using Pin, making it safer and easier to handle self-referential data structures without requiring unsafe code.

Use-case:
Reduces complexity and unsafe code when working with Pin in embedded drivers.

GitHub issue:
rust-lang/rust#130494

[manczak-ifx]

Add unsafe_pinned for better aliasing control

The unsafe_pinned feature provides explicit semantics for aliasing in heapless data structures, ensuring safety and clarity in resource-constrained environments.

Use-case:
Enables safe aliasing in memory-constrained, heapless embedded systems.

GitHub issue:
rust-lang/rust#125735

[manczak-ifx]

Enable atomic volatile for safer memory access

The "volatile 2.0" feature clarifies concurrency interactions for volatile operations, improving safety with DMA and shared memory in embedded systems.

Use-case:
Ensures safe and efficient volatile memory access in concurrent embedded environments.

GitHub issue:
rust-lang/unsafe-code-guidelines#321 (comment)

[jonathanpallant]

-Ctarget-cpu enables support for interesting architecture extensions, like Helium (aka M-Profile Vector Extensions) on -Ctarget-cpu=cortex-m55. But, it always turns on everything that CPU could possibly have, and then you have to turn off the stuff you don't have -Ctarget-features=-fpregs or similar if you don't have the FPU). It's all very messy.

See https://doc.rust-lang.org/nightly/rustc/platform-support/thumbv8m.main-none-eabi.html, which I was told off for adding because we aren't supposed to document unstable things in the Platform docs. No idea where it should be documented.

[jonathanpallant]

I lost 30 minutes of my life today to:

env:
  RUSTFLAGS: "-Dwarnings" 

in github CI, causing cargo to completely ignore this in my .cargo/config.toml:

[target.thumbv7em-none-eabihf]
rustflags = [
    "-Clink-arg=-Tlink.x",
    "-Clink-arg=-Tdefmt.x",
]

Those rustflags are load bearing and a lot of weird stuff will happen if you don't have them - failures like:

  = note: rust-lld: warning: cannot find entry symbol _start; not setting start address
          Error: "MEMORY.RAM not found after scanning linker scripts"
          

error: could not compile `qemu-app` (bin "qemu-app") due to 1 previous error
warning: build failed, waiting for other jobs to finish...

Doing RUSTFLAGS="-Ctarget-cpu=cortex-m4" cargo build will cause a similar failure.

I wish cargo was better at merging rustflags rather than entirely replacing them.

(Copy of #835 (reply in thread))