`static mut` transform is unsound on multi-core systems

[Disasm]

RP2040 starts execution on both cores. If entry function contains a "special" definition of static mut variable, each core takes a mutable reference to it, which is illegal from the Rust point of view.

Here is the relevant piece of #[entry] code: https://github.com/rust-embedded/cortex-m-rt/blob/ca4790f40738bcc770285c8080955a2077682078/macros/src/lib.rs#L87-L88

[jonas-schievink]

cortex-m-rt only supports single-core systems

[Disasm]

Is it stated anywhere apart from this comment?

[adamgreig]

Do the static mut transforms in the macros provide much value? I can't remember but I think we discussed removing them at some point, maybe involving rust-embedded/cortex-m#407/#250. Cortex-m's Mutex is definitely only single-core aware too, though, and I'm not sure what else would need changing in c-m-rt to make it safe on multi-core systems (at least, when they both execute the same code).

Doesn't the RP2040 ROM send the second core to sleep, so it only starts execution after being signalled once user code is running?

[jamesmunns]

Chiming in that this also applies to #[interrupt] macro, if the two cores share the same vector table/ISR functions.

[thejpster]

It's unsound where the interrupt function can be re-entered. The NVIC usually prohibits this but on a multi-core system you need something at the HAL level to ensure this. You can imagine a mechanism that moves ownership of system interrupts from one core to another, hiding the regular NVIC API from the user. Then it would still be sound.