Building Tock with stable rustc

[mcy]

This issue tracks attempting to build as many Tock libraries as possible with a stable compiler, that is, minimizing the number of #![feature(...)] pragmas used in lib.rs files.

Update Feb 2024

Cortex-M crates can now compile on stable!

Nightly Features

• (Update Nightly Oct 2022 and remove asm_sym feature #3303) asm_sym. Needed for sym operands in assembly blocks. Tracking Issue for asm_sym rust-lang/rust#93333 . Stabilized upstream on 10/18/22, we just need to update to a newer nightly.
• (????) asm_const. Needed for const operands in assembly blocks. Used in RISC-V CSR crate. The CSR crate will likely change with an upcoming change to tock-registers. Tracking Issue for asm_const rust-lang/rust#93332 Stabilise inline_const rust-lang/rust#104087
• (Remove #![feature(naked_functions)] and compile Cortex-M on stable! #3802) naked_functions. Used for initial entry point and interrupt handlers. Not clear if there is progress on stabilizing this (Tracking issue for naked fns (RFC #1201) rust-lang/rust#32408). Tracking Issue for RFC #2972: Constrained Naked Functions  rust-lang/rust#90957 (comment) Stabilize naked_functions rust-lang/rust#93587
• (Remove nightly-only target_feature #3803) #[cfg(target_feature = "v7")]. This is not a documented feature flag only available on nightly, but target_feature is only set for arm targets on nightly. You can see this by running rustc --target=thumbv7em-none-eabi --print cfg on nightly vs. stable.
• (kernel: remove core_intrinsics #3574) core_intrinsics. Intrinsics will never be stabilized, and are subject to unannounced changes by rustc's developers. We use three classes of intrinsics:
  • (RFC: Restructure DeferredCall to not require atomics #3086 ) core::intrinsics::atomic_*, various atomic intrinsics. These will be very difficult to get rid of due to how Rust decides to provide AtomicT types, and, in the case of kernel's AtomicUsize will require consultation with an atomics expert. These intrinsics are only used for the DeferredCall mechanism, and discussion on the Tock core call indicates that DeferredCall likely can be rewritten to not require atomics, given that the Tock kernel design guarantees non-reentrancy of all interactions with DeferredCall. A PR that safely removes the use of atomics in the kernel is welcome.
  • (Remove core_intrinsics offset feature #1957) core::intrinsics::offset, which is just pointer arithmetic. We should be using <*mut T>::offset, which is guaranteed to have the same effect and the same optimization characteristics.
  • (Remove core::intrinsics::math #1958) core::intrinsics::sqrtf32, a square root intrinsic. f32::sqrt is not present in core even though it just calls the intrinsic. This is because on many platforms, the intrinsic expands into a libm call, though not on any platforms Tock is built for. Removing this may require implementing a polyfill in assembly.
• (????) custom_test_frameworks. Used to test boards. Tracking issue for eRFC 2318, Custom test frameworks rust-lang/rust#50297
• (????) -Z build-std=core, compiler_builtins. Added in use -Zbuild-std=core to build the std library with our optimization settings #2847. Builds a more optimized library, but uses an unstable flag. Doc: https://doc.rust-lang.org/cargo/reference/unstable.html#build-std. Related repo: https://github.com/rust-lang/wg-cargo-std-aware.
• (???) -Z virtual-function-elimination. Added in Update Rust nightly version + Expose virtual-function-elimination #3072 . Removes uncalled virtual functions from LTO'ed binaries, but uses an unstable flag as it can sometimes be too aggressive. This is not used by default, and must be specifically requested by setting an environment variable (VFUNC_ELIM=1).
• (Update Nightly to Feb 2022 #2959) asm. Assembly is a hard requirement for any kernel, it is possible to move all of it into .S files instead. Tracking issue for asm!(): Tracking Issue for inline assembly (asm!) rust-lang/rust#72016.
• (Remove const_fn_trait_bound feature and update nightly (Mar 2022) #2988) const_fn_trait_bound. What used to be const_fn has been broken into smaller changes, and we only require one that is still unstable: const functions with a bound type parameter. The Tock register interface uses const_fn extensively, and it is an open question what it would take to forego this. Fortunately, the stabilization PR has been merged, so we should be able to remove feature(const_fn_trait_bound) at our next toolchain update.
• (Remove #![feature(const_mut_refs)] #3082) const_mut_refs. Used in tock-cells and lowrisc chip. Tracking issue for &mut T in const contexts (const_mut_refs) rust-lang/rust#57349
• (libraries: cells: remove option_result_contains #2964) option_result_contains. Tracking issue for Option::contains and Result::contains rust-lang/rust#62358 . We could easily reimplement this. Branch ready: https://github.com/tock/tock/compare/remove-option_result_contains.
• ([Tracking] Convert from llvm_asm!() to new asm!() #1923) llvm_asm. Replaced by asm!().
• (????) try_trait. Used in the kernel, for tbf parsing. But at some point we stopped using it.
• (Remove associated_type_defaults feature #2346) associated_type_defaults. Allows declaring defaults for associated types in trait definitions. We only use it in two places, and in both cases we can remove it just by adding type parameters in a few places that we currently do not (MPUConfig and Component::StaticInput). Only partially implemented in the compiler right now, but seems to be nearing completion? Tracking issue for RFC 2532, "Associated type defaults" rust-lang/rust#29661 .
• (remove all uses of unstable const_in_array_repeat_expressions feature #2215 ) const_in_array_repeat_expressions. Used to allow for ergonomic components for scheduler initialization. Could be replaced by using recursive macros for array declarations instead, which is @hudson-ayers responsibility if this ever becomes the lone blocker. Tracking issue: Tracking issue for RFC 2203, "Constants in array repeat expressions" rust-lang/rust#49147 . Fixed by remove all uses of unstable const_in_array_repeat_expressions feature #2215
• (rust: remove all unused feature pragmas #1643) Remove all pragmas currently not required to build Tock.
• (remove all uses of lang_items unstable feature #1950 ) lang_items. The main purpose of this pragma is declaring the global panic handler in a no_std binary. A mechanism for this has been stabilized, and remove all uses of lang_items unstable feature #1950 should remove all uses of it.
• (rust: remove all uses of unstable pragma "in_band_lifetimes" #1646) in_band_lifetimes. This is syntax sugar that makes otherwise undeclared lifetimes become defined, by adding lifetime declarations where necessary. In other words, the transformation fn foo(_: &'a T) -> fn foo<'a>(_: &'a T). The "placeholder lifetime", '_, is a stable feature that acts as an in-band lifetime which does not bind a name, and which was originally part of in_band_lifetimes. Since the stabilization of '_, the stabilization of in_band_lifetimes has been deprioritized, and is fairly unlikely to happen in its current form.
• (chips/saml4: remove unstable pragma #1649) concat_idents. Used in just one macro that doesn't actually need it. Given that it is basically unusable, Rust is very reluctant to ever stabilize it.
• (kernel: remove unstable crate_visibility_modifier, aka crate -> pub(crate) #1650) crate_visibility_modifier. Allows crate in item position as sugar for pub(crate). Interest in this feature appears to have died down after the 2018 module system shakeup, and provides no value other than saving five characters.
• (kernel: use NonNull, iterate on grant and appslice interfaces #1648) ptr_internals. Allows use of core::ptr::Unique. This is an internal of Box that will never be stabilized. core::ptr::NonNull is a drop-in replacement.
• (chips/e310x: Remove unstable pragma #1647) exclusive_range_pattern. Allows use of a..b as a pattern. Only used in one place (used incorrectly, too).
• (kernel: remove panic_info_message feature #1955) panic_info_message. Used in one place by kernel to dump panic information. Might want to get rid of it, since it seems the API might get tossed out in favor of something else: Tracking issue for PanicInfo::message rust-lang/rust#66745
• (Handle device register aliases explicitly #1661) untagged_unions. Allows putting non-Copy traits in unions. Using this is basically asking for weird dtor behavior and general unsoundness. We use it in one place, and can probably just plug the hole with the stable DropManually API (which is just an untagged_union without sharp edges).

This work is especially attractive to OpenTitan's use of Tock as a secure embedded operating system. Being able to build code without exercising unstable (and, as such, untested and unproven) code paths in the compiler increases confidence in the language-level and hardware-level guarantees provided by Tock. This is not to mention that unstable features are not guaranteed to be stabilized, or to remain in the compiler indefinitely.

This work is divided up according to pragmas still present after #1643, which every pragma that could be removed without causing build failures. Below is a list of all pragmas Tock still uses.

Please comment additional pragmas below as they are used, or edit this list to include them if you have write access.

[alevy]

Thanks @mcy, this is excellent!

[pfmooney]

Indeed. Thanks for your work on this.

asm and naked_functions. Assembly is a hard requirement for any kernel, it is possible to move all of it into .S files instead. This will require build system work to invoke LLVM's assembler through clang or similar. There have been attempts to stabilize this recently (which I have been involved in); driving stabilization forward is also an option, though the stable syntax is likely to be incompatible with the current one, which is just a Clang/GCC dialect.

If there are any other features which mandate sticking with nightly in the short-to-medium term, I hope we would keep asm and naked_functions so this code could remain inline until the "native" rust option stabilizes.

[mcy]

Regarding inline assembly, there seems to be some degree of contention on whether inline assembly is even a good idea, in principle (I mostly lean towards the .S side but that's because I think GCC/Clang constraint syntax is hot garbage). I still need to look into pushing stabilization forward; I was very involved in the most recent effort to specify a syntax (I yelled at them very loudly to explicitly support RISC-V).

We can answer the question of inline assembly later; plowing through the other bullet points will probably take me a while, and I think the fate of inline assembly is RFC-worthy.

[bradjc]

The tension in the initial pull requests is, I think, getting at a deeper issue than just switching toolchains. Pushing towards using stable represents a change in how Tock views Rust. When we started, just creating any architecture for an OS for embedded systems using Rust that an embedded engineer would understand and find reasonable was a challenge, given the disconnect between how embedded software is traditionally written and Rust's ownership model. But, we thought it was worth seeing if Rust could provide any benefit. As Tock developed, the attitude of "let's see what tools Rust can give us" persisted, and I think that has manifested as a willingness to embrace new features of the language and explore how they can be used, like:

• Do they help with sharing code between embedded platforms?
• Do they make it easier for a C programmer to understand Rust?
• Can we remove Tock-specific code and use Rust-provided abstractions instead?
• Can we eliminate unsafe and the chance for panics?

So, the question might be, is now the right time to say we expect to be able to leverage fewer Rust features to our benefit, and are better served with the stable toolchain? Or is Rust continuing to push with new features that will make it easier to develop Tock, and we shouldn't miss out/delay their use for months? Or has Tock progressed enough that its goals on this issue should change?

---

My opinion has been that if we can't use stable anyway (because of assembly), then we shouldn't be in this halfway state where we have to use the nightly toolchain, but then also don't get to try out any of its new features. Now, however, if there is a reasonable roadmap to switching to the stable compiler then it might be worth making the change. But, I'm not sure that March 2020 is the deadline to say that if a feature has not been stabilized by now, then Tock cannot use it. I would rather wait until a switch to stable is imminent. Maybe this could be part of Tock 2.0?

[gendx]

Thanks for setting up the list and starting cleaning up the low-hanging fruits!

My comment would go in the opposite direction, but is also quite hypothetical at this stage. Anyway, since we're discussing unstable features here, what about adding more features in the future?

I'm mostly thinking about const generics (which are still highly unstable and not usable for many cases yet, hence the "hypothetical"). However, I see them bringing value in Tock as well.

In particular, because dynamic memory allocation is restricted in Tock, many structures are defined as constant or static arrays of a const size. This means that either the size is fixed and unconfigurable, or we have to pass slices around to support tuning the size for each board or to quickly modify it. Slices have their own set of problems, notably that a suitable lifetime (usually 'static) has to be passed around, and that the Rust compiler limits what's possible w.r.t. statics and w.r.t. borrowing.

Here are a couple of example where I see them bringing value in Tock

• It was proposed recently in RFC: use const generics for ipc arrays #1585 to have IPC array take a const generic size.
• Another example that comes to mind is the RingBuffer, which currently takes a slice. It'd be useful to have ring buffer incorporating their own array, but that requires either separately creating a static array (which can be quite tricky given Rust's borrowing rules and limitations around statics), using something like Pin to be able to have a self-referential struct, or using const generics. Here are a couple examples.

// Self-referential struct
struct SelfRingBuffer<T> {
    // Easy to change the size.
    array: [T; 16],
    // Intrusive ring buffer which should reference &self.array.
    ring_buffer: RingBuffer<T>,
}

// Const-generic struct.
struct FixedRingBuffer<T, const N: usize> {
    array: [T; N],
    head: usize,
    tail: usize,
}

In many cases, macros could be used to simulate const-generics, but I don't think that'd be clearer (e.g. worse error messages, not the same level of type checking).

Of course, this is still highly hypothetical as const-generics are not nearly stable enough, but on the other hand given the value they will bring to the Rust ecosystem as a whole, I don't see them as a feature being abandoned by the community - and they will likely eventually be stabilized (although no idea when).

So my question is: what's Tock position regarding adding new unstable features in the future? What bar (current and future stability? value proposition?) should an unstable feature pass to be used in Tock?

[ppannuto]

So my question is: what's Tock position regarding adding new unstable features in the future? What bar (current and future stability? value proposition?) should an unstable feature pass to be used in Tock?

I think historically the answer has been "no bar". If it's in the officially released nightly compiler, it's fair game. We've viewed Tock as a project written in the language "unstable Rust" so anything in the official language (as defined by the compiler that exists for it) is valid.

[gendx]

I think historically the answer has been "no bar". If it's in the officially released nightly compiler, it's fair game. We've viewed Tock as a project written in the language "unstable Rust" so anything in the official language (as defined by the compiler that exists for it) is valid.

I think we should be a bit more nuanced than "whatever is possible today is valid". We regularly update the compiler version (e.g. due to compiler bugs, or to adopt more recent features). I don't think Tock should end up in a situation where:

• Some shiny_feature is available on week 1. We jump on it to implement some cool component.
• On week 2, a new compiler has more_shiny_feature, supports CPU architecture awesome and fixes a critical bug in the nightly compiler, but shiny_feature isn't available anymore.

What should we do? Stay stuck on week 1's compiler? Rollback all the changes to migrate to week 2?

This is of course an extreme example, and the Rust compiler has generally been good at avoiding such situations even in nightly (especially given how many projects rely on nightly for the unstable features that it provides). But the more features we use, the riskier it is to end up in such a situation.

Another possible problem is if the nightly of day D has a critical bug, because it's nightly.

For better or worse, Rust is sometimes slow at stabilizing features, which makes nightly more appealing to many projects. But trimming down to "essential" features only (with a minimal bar for allowed features) can reduce the risks, especially as Tock grows to more stakeholders (more developers, more architectures/boards, more applications).

[gkelly]

So my question is: what's Tock position regarding adding new unstable features in the future? What bar (current and future stability? value proposition?) should an unstable feature pass to be used in Tock?

I think historically the answer has been "no bar". If it's in the officially released nightly compiler, it's fair game. We've viewed Tock as a project written in the language "unstable Rust" so anything in the official language (as defined by the compiler that exists for it) is valid.

I believe that there's a strong argument to be made from a safety standpoint for using stable rust. I believe the unstable features receive significantly less testing than the core stable set, just by virtue of fewer programs ever getting written against them. I also worry about features rotting. Just because it was safe at the original time of implementation to depend on that feature I don't feel comfortable depending on ones who have no clear path to inclusion in rust-stable. If the feature does break the only recourse we have is to fix it after the fact.

[pfmooney]

untagged_unions. Allows putting non-Copy traits in unions. Using this is basically asking for weird dtor behavior and general unsoundness. We use it in one place, and can probably just plug the hole with the stable DropManually API (which is just an untagged_union without sharp edges).

Looking at the one piece of code using this, it seems we could solve the specific case by extending tock-registers to support a dual-type mode for device registers which have different behavior/formats for read and write.

[phil-levis]

My opinion has been that if we can't use stable anyway (because of assembly),

I'll go on the record saying I've always been against inline assembly. I'd prefer to just write assembly, follow the C ABI, and then import these functions into Rust as C functions. This is what I do in my (non-Tock) embedded systems work.

[pfmooney]

I'll go on the record saying I've always been against inline assembly. I'd prefer to just write assembly, follow the C ABI, and then import these functions into Rust as C functions. This is what I do in my (non-Tock) embedded systems work.

There are a few cases, like the riscv-csr crate, which would be onerous to implement in that fashion. (The CSR identifier is a constant immediate in the instructions, so the rust compiler smarts are pretty great at enabling a nice interface for crate consumers)

[bradjc]

Any thoughts on try_trait rust-lang/rust#42327? That proved to be very useful in #1480.

[alevy]

Any thoughts on try_trait rust-lang/rust#42327? That proved to be very useful in #1480.

@bradjc I believe this has a very high chance of becoming stable in the not far future.

[bradjc]

Any thoughts on cell_update rust-lang/rust#50186? It is used in #1718.

[alistair23]

cell_update looks useful, but we can always just take() and then replace() the Cell value so it doesn't let us do something we couldn't already.

[lschuermann]

Indeed. However it let's us write code in a way more aligned to what's commonly done with TakeCell and MapCell. I often tend to forget the set() part of the Cell update. It's only development ergonomics, and I'm fine either way - with or without the feature.

[lschuermann]

I'm using associated_type_defaults rust-lang/rust#29661 in #1727 too. Can be easily removed though, if it doesn't become stable in the near future.

[bradjc]

Does anyone know how we can support DefferedCall (which uses AtomicUsize) on earlgrey (rv32imc) without core_intrinsics?

[hudson-ayers]

Does anyone know how we can support DeferedCall (which uses AtomicUsize) on earlgrey (rv32imc) without core_intrinsics?

(I might be exposing myself here as not understanding something as well as I should).

Why does DeferedCall require atomics? I don't think I was particularly involved at the time they were introduced, but here is my understanding of how they work:

1. They are only set from within the kernel

2. They are never set from interrupt context

3. They are never read from interrupt context

4. We only ever have 1 kernel thread, so effectively all of these things are done from the same thread.

So why is it necessary that setting deferred calls or servicing them requires atomics? Can we not just use a cell?

For anyone curious, #687 seems to have originally added DeferredCall, and I couldn't find a description there for why atomics are needed either.

[hudson-ayers]

I updated the top level comment with my understanding of the current state of things. To summarize remaining major blockers:

1. Transition all llvm_asm!() --> asm!(), and wait for asm!() to stabilize. Ideally, we should encourage new contributions to use the new macro.

2. core_intrinsics. To remove all uses of atomics in the Kernel, we need to modify DeferredCall to not use atomics. This should be safe to do given the design of the Tock kernel, but will require careful review.

3. const_fn. Board-based instantiation of chip drivers and interrupt --> driver mapping for Apollo3 + SAM4L #2069 presents a design that makes removal of almost all uses of const_fn possible. But the tock register interface still requires it, and removing its use there may be difficult, and is IMO the only remaining open question on the journey to stable.

I think all other remaining features could be removed without too much effort, but deserve to be used for now in the event that they become stabilized before these blockers are resolved.

[hudson-ayers]

Update of major blockers to stable Rust:

1. core_intrinsics. As before, I still believe this could be safely removed with just some implementation effort.
2. asm_sym + naked_functions: Removing either of these would be very difficult, but both have been nominated for stabilization (and naked_functions has been approved for stabilization), so these are no longer much of a concern.
3. asm_const: Only one use remains after Remove one use of asm_const #3083 is merged. This use in in riscv_csr. Removing that use would require going back to either the switch statement approach to CSRs (e.g. before https://github.com/tock/tock/pull/2472/files), or revisiting the macro-based approach that Alistair suggested (https://github.com/tock/tock/pull/2470/files), but is certainly technically possible at the expense of that file being harder to maintain.

Everything else is either in boards/ or an option passed in our Makefile, and as such does not prevent any downstream user from using stable Rust, and as such less important to resolve.