Expose `abort` function from core

[m-ou-se]

It seems like core knows how to abort a program (it has core::intrinsics::abort), but only std exposes this functionality.

In some rare cases, a potentially unwinding panic might lead to unsoundness, where an abort would do a better job. A good example is the implementation of Arc.

The very same situation occurs in the atomic_refcell crate. As there is nothing else in the crate depending on std it should be a no_std crate. However, that change replaces the std exit/abort call with an ugly hack using a double-panic to try to cause an abort.

Instead, a stable abort function in core would be a lot nicer.

[jonas-schievink]

This would also be useful to get panic-abort compiling on stable.

One issue with this is what the behavior on #![no_std] targets should be. In std, it's relatively clear that the process is aborted by the OS, but what should happen when there is no OS? Should it lower to some architecture-specific abort instruction (sequence)? Should we document what that sequence looks like, or would eg. an infinite loop also be a correct implementation?

[Aaron1011]

Should be document what that sequence looks like, or would eg. an infinite loop also be a correct implementation?

I don't think an infinite loop would be very useful - users can already get that by doing #[cfg(target_os = "something")] loop {}

[m-ou-se]

would eg. an infinite loop also be a correct implementation?

That would only lock up a single thread. In the two examples I gave, it's important that all threads/interrupt handlers/... are aborted.

There's some documentation about the current behaviour of core::intrinsics::abort in the panic-abort docs.

[nagisa]

Executing an invalid instruction on multi-core bare metal targets won't halt the other cpus. Stopping other cores will be a responsibility of your interrupt handler.

[jonas-schievink]

An alternative to a generic abort function would be to add wrappers around specific instructions to core::arch and use those. The downside would be that that is inherently architecture-specific, but the upside is that it is very clear what those function do, which should simplify stabilization (and we – the embedded WG – want to have those specific functions in any case since they have other uses).