`interrupt::free` is not enough to access `static mut` safely

[jonas-schievink]

At least in the presence of multiple cores sharing the same set of statics. Problematic code:

cortex-m-semihosting/src/export.rs

Lines 9 to 19 in 7a961f0

	static mut HSTDOUT: Option<HStdout> = None;
	pub fn hstdout_str(s: &str) -> Result<(), ()> {
	interrupt::free(|_| unsafe {
	if HSTDOUT.is_none() {
	HSTDOUT = Some(hio::hstdout()?);
	}
	HSTDOUT.as_mut().unwrap().write_str(s).map_err(drop)
	})
	}

[jonas-schievink]

This point might be moot. There's not really a way to solve this, and all other foundational crates also use interrupt::free. I don't usually work with multi-core chips, but I suppose we need another solution for them (are there any devices/use cases where you'd share statics between cores?).

[jonas-schievink]

This may be resolved by rust-embedded/wg#388

[japaric]

This may be resolved by rust-embedded/wg#388

I don't see how that solves the problem. hprintln!, which calls this function, is global and can be called from any core. It's not even protected by bare_metal::Mutex at the moment and if it were with the linked RFC it would simply stop to compile.

One potential solution would be use AtomicUsize to store the file descriptor and use something like usize::max_value to mean None. That would synchronize the open syscall between cores but then more than one core would end up using the same file descriptor. What's the observed behavior of using the same file descriptor from different cores in parallel? I personally don't know because I have never gotten multi-core debugging working (OpenOCD / pyOCD / JLink only worked on one core at a time when I tried them on multi-core Cortex-M SoCs)

The other option is to have a core-local variable to store the file descriptor then each core gets its own file descriptor. Again, I don't know whether parallel semihosting writes using different file descriptors actually works in multi-core context. Leaving that aside, the problem is that there's no support in the Cortex-M ISA to differentiate one core from the other, unlike say RISC-V which has a "thread local pointer" (don't remember the exact name) register for this purpose.

[adamgreig]

This is closed by virtue of our decision to basically not support SMP.