avr: Provide abort()

[Patryk27]

On AVRs, an architecture that doesn't support traps, unreachable code paths get lowered into calls to an intrinsic called abort:

https://github.com/llvm/llvm-project/blob/cbe8f3ad7621e402b050e768f400ff0d19c3aedd/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp#L4462

avr-gcc doesn't provide this function, presumably because they deal with traps in some other way, so when LLVM decides not to optimize those unreachable code paths out (spotted over Rahix/avr-hal#651 and rust-lang/rust#139737), currently the linker fails with undefined reference.

It doesn't have to, though, because we can provide a valid implementation of this intrinsic right here.

Note that while we could shove this responsibility to end users, same way we do with #[panic_handler], traps don't really allow to recover in a generic way - abort() is called when an unexpected code path gets exercised, so for all we know the environment (especially the Rust's stdlib part of it) is gone by then, there's no point in calling panic!() or anything else.

At the same time, some people might want to provide their own recovery mechanism (doing whatever magic they want), so let's mark this intrinsic as weak, so that it can be overridden if someone wants to (in particular, a safe-ish way to implement it would be to use inline assembly to manually manipulate registers to blink a LED, for instance).

cc @tgross35

[tgross35]

Is it possible to use the intrinsics! macro here?

Providing this seems fine to me but @bjorn3 are there any concerns here?

[Patryk27]

Sure, done!

[EvansJahja]

Thank you for taking the issue.

I'm wondering if it is the right thing to do to provide a default implementation that loop. My concern is that users that are unaware of this behavior might be running their code and suddenly it locks up without much explanation. With panic handlers it was made obvious that you have to provide a panic handler, but with this, now it just locks up silently.

Is it possible to emit a warning mentioning that users should either provide their own abort otherwise the default implementation of loop{} will be used?

[tgross35]

Sorry about the CI noise, noise from the recent libm merge. Should go away with a rebase (I think...)

[Patryk27]

My concern is that users that are unaware of this behavior might be running their code and suddenly it locks up without much explanation.

I see, I just think there's not much of other behavior that can happen here - you can't reliably restart the chip (if it's connected to some other chips via SPI etc., those wouldn't be restarted) etc., so while a lockup is unfortunate, it's also not really expected to happen in practice (after all, those are supposed to be unreachable code paths).

Is it possible to emit a warning mentioning that users should either provide their own abort otherwise the default implementation of loop{} will be used?

We could certainly document it, but I'm not sure if there's a way to provide a warning - the thing is that you can pull abort() from outside of Rust code (by side-linking it from a library), so throwing a warning from rustc would be checking it too early, this warning would have to be done by the linker.

Once we drop avr-gcc and switch to LLVM's linker we could experiment there, but for the time being I'm not sure if there's something better we can do - I'm open to suggestions, of course!

Just note that abort(), except for when called explicitly through code::intrinsics::abort(), is opportunistic - instead of calling it, LLVM might simply not generate any instruction whatsoever (i.e. on unreachable paths the control will flow to the next block / next function, with totally broken assumptions) etc., so users mustn't rely on it being a protection layer.

[tgross35]

LGTM, but I think you will need to rebase

[tgross35]

Or I guess I can :) thanks!