Merge #423

423: Swap to just-stabilised asm!() and global_asm!() macros r=thejpster a=adamgreig

Once Rust 1.59 is released in a couple of days, the `asm!()` and `global_asm!()` macros will become stable, and we will no longer require the various precompiled binaries we've used until now in cortex-m and cortex-m-rt. cc #420.

This PR uses `asm!()` in cortex-m, and removes the inline-asm feature, since I anticipate this going into cortex-m 0.8 and so we don't need to leave it behind for compatibility. In various places the previous version would call an extern C method when built for the native target, which would only fail at link time; to preserve the ability to build on x86 I've either made the whole method require the `cortex_m` configuration, or where appropriate/convenient simply skipped the `asm!()` call.

This PR replaces the old gcc-preprocessed `asm.S` in cortex-m-rt with use of `global_asm!()`, although since you can't normally use `#[cfg(...)]` attributes with `global_asm!()`, there's also a slightly scary macro modified from one invented by `@Dirbaio` for a similar purpose. I considered putting the initialisation of LR behind an armv6m flag, but since we want to restore it after calling `__pre_init` it seemed better to just leave it the same on both targets. I added Cargo features to optionally set SP and VTOR at startup, which has been variously requested but would previously have required multiplicatively more pre-built binaries. Now: no problem. Relevant issues:

* https://github.com/rust-embedded/cortex-m-rt/issues/283
* https://github.com/rust-embedded/cortex-m-rt/issues/55
* https://github.com/rust-embedded/cortex-m-rt/issues/254
* https://github.com/rust-embedded/cortex-m-rt/issues/102
* https://github.com/rust-embedded/cortex-m-rt/pull/338

I've tested these on a couple of targets (and updated the CI): on the whole there's a small improvement in code size due to everyone getting inlined asm, especially in `cortex_m::interrupt::free()`.

The major downside is we bump our MSRV from 1.42 (March 2020) to 1.59 (Feb 2022). For cortex-m, I propose putting these changes in the upcoming 0.8 release (which is technically what the master branch is already on) and not backporting. For cortex-m-rt I'm not sure: we don't have any other pending breaking changes, so we could consider a patch release. Anyway, this PR doesn't commit to any particular releases, so we can decide that later.

For cortex-m-semihosting/panic-semihosting I think a patch release would be ideal, especially since we had to yank the last c-m-sh release due to conflicting prebuilt binaries (a problem that should now vanish).

Also tagging these issues that I think might also benefit from new inline asm:
* https://github.com/rust-embedded/cortex-m/issues/265
* https://github.com/rust-embedded/cortex-m/issues/215
* https://github.com/rust-embedded/cortex-m/issues/406

Co-authored-by: Adam Greig <adam@adamgreig.com>

1 files changed, 0 insertions, 143 deletions

diff --git a/asm/lib.rs b/asm/lib.rs
deleted file mode 100644
index 48f3dc2..0000000
--- a/asm/lib.rs
+++ /dev/null
@@ -1,143 +0,0 @@
-//! FFI shim around the inline assembly in `inline.rs`.
-//!
-//! We use this file to precompile some assembly stubs into the static libraries you can find in
-//! `bin`. Apps using the `cortex-m` crate then link against those static libraries and don't need
-//! to build this file themselves.
-//!
-//! Nowadays the assembly stubs are no longer actual assembly files, but actually just this small
-//! Rust crate that uses unstable inline assembly, coupled with the `xtask` tool to invoke rustc
-//! and build the files.
-//!
-//! Precompiling this to a static lib allows users to call assembly routines from stable Rust, but
-//! also perform [linker plugin LTO] with the precompiled artifacts to completely inline the
-//! assembly routines into their code, which brings the "outline assembly" on par with "real" inline
-//! assembly.
-//!
-//! For developers and contributors to `cortex-m`, this setup means that they don't have to install
-//! any binutils, assembler, or C compiler to hack on the crate. All they need is to run `cargo
-//! xtask assemble` to rebuild the archives from this file.
-//!
-//! Cool, right?
-//!
-//! # Rust version management
-//!
-//! Since inline assembly is still unstable, and we want to ensure that the created blobs are
-//! up-to-date in CI, we have to pin the nightly version we use for this. The nightly toolchain is
-//! stored in `asm-toolchain`.
-//!
-//! The `cargo xtask` automation will automatically install the `asm-toolchain` as well as all
-//! Cortex-M targets needed to generate the blobs.
-//!
-//! [linker plugin LTO]: https://doc.rust-lang.org/stable/rustc/linker-plugin-lto.html
-
-#![feature(asm)]
-#![no_std]
-#![crate_type = "staticlib"]
-#![deny(warnings)]
-// Don't warn about feature(asm) being stable on Rust >= 1.59.0
-#![allow(stable_features)]
-
-mod inline;
-
-macro_rules! shims {
-    (
-        $( fn $name:ident( $($arg:ident: $argty:ty),* ) $(-> $ret:ty)?; )+
-    ) => {
-        $(
-            #[no_mangle]
-            pub unsafe extern "C" fn $name(
-                $($arg: $argty),*
-            ) $(-> $ret)? {
-                crate::inline::$name($($arg),*)
-            }
-        )+
-    };
-}
-
-shims! {
-    fn __bkpt();
-    fn __control_r() -> u32;
-    fn __control_w(w: u32);
-    fn __cpsid();
-    fn __cpsie();
-    fn __delay(cyc: u32);
-    fn __dmb();
-    fn __dsb();
-    fn __isb();
-    fn __msp_r() -> u32;
-    fn __msp_w(val: u32);
-    fn __nop();
-    fn __primask_r() -> u32;
-    fn __psp_r() -> u32;
-    fn __psp_w(val: u32);
-    fn __sev();
-    fn __udf() -> !;
-    fn __wfe();
-    fn __wfi();
-    fn __sh_syscall(nr: u32, arg: u32) -> u32;
-    fn __bootstrap(msp: u32, rv: u32) -> !;
-}
-
-// v7m *AND* v8m.main, but *NOT* v8m.base
-#[cfg(any(armv7m, armv8m_main))]
-shims! {
-    fn __basepri_max(val: u8);
-    fn __basepri_r() -> u8;
-    fn __basepri_w(val: u8);
-    fn __faultmask_r() -> u32;
-    fn __enable_icache();
-    fn __enable_dcache();
-}
-
-#[cfg(armv7em)]
-shims! {
-    fn __basepri_max_cm7_r0p1(val: u8);
-    fn __basepri_w_cm7_r0p1(val: u8);
-}
-
-// Baseline and Mainline.
-#[cfg(armv8m)]
-shims! {
-    fn __tt(target: u32) -> u32;
-    fn __ttt(target: u32) -> u32;
-    fn __tta(target: u32) -> u32;
-    fn __ttat(target: u32) -> u32;
-    fn __msp_ns_r() -> u32;
-    fn __msp_ns_w(val: u32);
-    fn __bxns(val: u32);
-}
-
-// Mainline only.
-#[cfg(armv8m_main)]
-shims! {
-    fn __msplim_r() -> u32;
-    fn __msplim_w(val: u32);
-    fn __psplim_r() -> u32;
-    fn __psplim_w(val: u32);
-}
-
-// All targets with FPU.
-#[cfg(has_fpu)]
-shims! {
-    fn __fpscr_r() -> u32;
-    fn __fpscr_w(val: u32);
-}
-
-/// We *must* define a panic handler here, even though nothing here should ever be able to panic.
-///
-/// We prove that nothing will ever panic by calling a function that doesn't exist. If the panic
-/// handler gets linked in, this causes a linker error. We always build this file with optimizations
-/// enabled, but even without them the panic handler should never be linked in.
-#[panic_handler]
-#[link_section = ".text.asm_panic_handler"]
-fn panic(_: &core::panic::PanicInfo) -> ! {
-    extern "C" {
-        #[link_name = "cortex-m internal error: panic handler not optimized out, please file an \
-        issue at https://github.com/rust-embedded/cortex-m"]
-        fn __cortex_m_should_not_panic() -> !;
-    }
-
-    unsafe {
-        __cortex_m_should_not_panic();
-    }
-}