`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 #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.

[9names]

The NVIC usually prohibits this but on a multi-core system you need something at the HAL level to ensure this.

You can also re-enable interrupts inside an interrupt and get the same problem.

In spite of rp2040 being around for several years we haven't had a single report of anyone having issues with this.

Rather than trying to make this safe, I think we should just document that you should not do anything that allows concurrent/recurrent execution of interrupt handlers and leave it at that, since the actual real-world usages of this behaviour are exceptionally rare, and even in the absence of the static mut transform are likely to be unsafe.

[jannic]

In spite of rp2040 being around for several years we haven't had a single report of anyone having issues with this.

I'm not sure if this is a strong argument. Having two instances of &mut references to the same underlying static is instant UB, but that doesn't guarantee that something bad happens. And even if it somehow breaks the software, it may happen very occasional, basically impossible to reproduce, and with non-obvious symptoms. So it may be dismissed as a flaky device and never be traced back to the underlying cause.

IMHO if we know that there are conditions that the user must hold up to avoid UB, there should be at least one unsafe function with a useful safety comment, so the user has a fair chance of knowing about these requirements, and a point to start looking for UB in case the software doesn't work as expected.

[thejpster]

It should go behind a flag, like the cs impl. Maybe even the same flag.