Note that implementing panic!
as abort
or an infinite loop is a perfectly fine strategy.
panic = "abort"
is handled by cargo, and panic by infinite loop is an oft used strategy on embedded platforms lacking the abort functionality.
Compiling to C is indeed only the first step in getting support on a platform; it's also the most problematic.
As a software developer, writing a run-time library, especially one with limited capabilities, is much easier. It does not even require hacking on the compiler (a much bigger bar to admission).
A stubbed-out minimal C run-time library could be provided, with a // TODO
in all implementations. Implement panicking with an infinite loop, return 0
or NULL
whenever necessary, etc... just enough for the thing to compile and allow the user to link a complete binary.
Then it's up to the user to implement the necessary parts of the stub for their platform.
It would also be possible to provide an implementation based on libc
; after all, if we are compiling to C, chances are that there is a C standard library available. It just should not be the only option since for embedded platforms there may not be anything available.