It doesn't require one. If you compile for a bare metal microcontroller, for example, you're probably running zero C code in your firmware image, so the only "

It doesn't require one. If you compile for a bare metal microcontroller, for example, you're probably running zero C code in your firmware image, so the only "ABI" that matters is how the hardware sets up register state at reset and for interrupts. Usually interrupt handlers are written in assembly anyway, but there's at one platform where someone modified the Rust compiler with a custom calling convention to allow writing interrupt handlers directly in Rust. [1] However, if you do have any assembly code in your project (for interrupt handlers or anything else), and it needs to call Rust or be called by it (likely), then you do want to mark the call (on Rust's end) as using the "C" ABI – simply because it is well-defined, while the Rust ABI is intentionally undefined. For now. Well-defined by what, you ask? Well, by whatever ABI or ABIs LLVM has been taught about for that architecture. The details of each ABI are baked into LLVM's source code, but often there's more than one ABI available for a given architecture, with different origins, and the compiler provides a flag to choose between them. There are also various customization options. Normally, the choice of OS determines the proper values for all those options, but if you're writing your own OS… you can set whatever you want. Of course, you could also define an ABI from scratch, if you feel like hacking up LLVM to support it. [1] https://stackoverflow.com/a/43392404 https://stackoverflow.com/a/43392404