Stream: cranelift

Topic: x86-interrupt ABI

Finchie (Aug 26 2026 at 07:25):

Hey all! I've been using Cranelift to compile a Rust x86 kernel and have run into the x86-interrupt ABI not being supported (at least from what I can tell). It seems like adding a new ABI is quite a maintenance burden so I'm curious if this is something that could be added in the future, or if it's a bit out of scope for the project's goals? The only mention I've seen of this is in a tracking issue on rustc_codegen_cranelift which seems to indicate interest, but would love to know what you all think!

fitzgen (he/him) (Aug 26 2026 at 16:05):

new ABIs aren't the highest maintenance burden in the world, but they aren't free. also if they share 95% of code with the system ABI that makes them a bit easier to swallow. I am not familiar with x86-interrupt (is this a standard x86(-64?) thing? an LLVM-ism?) and how similar or dissimilar it is to sys v. also the motivation for adding the ABI makes a difference. basically, I guess I am asking for more details :)

Finchie (Aug 27 2026 at 07:27):

As far as I understand it the ABI is roughly as follows:

• All registers are callee-saved and there are up to 2 parameters that are passed through the stack
• Functions must return using iret instead of the usual ret instruction

To my knowledge handling this ABI is pretty much mandatory for x86 kernels (in 16, 32 and 64 bit modes), and is supported by clang, gcc, msvc, etc. If I'm able to find the time, I'd love to have a look at adding support for it as it'd unblock Cranelift compilation for my project - not sure if it's the only blocker for other x86 kernels/operating systems but I'd expect it'd be one of the major ones.

Some links that might be useful:

• https://osdev.wiki/wiki/Interrupt_Service_Routines#Compiler_Specific_Interrupt_Directives
• https://github.com/rust-lang/rust/issues/40180
• https://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html
• https://github.com/rust-lang/rustc_codegen_cranelift/issues/1208

bjorn3 (Aug 27 2026 at 09:27):

and there are up to 2 parameters that are passed through the stack

Those 2 parameters are handled specially though. One of them (the error code) is stored at a fixed stack offset, but the other is a pointer to a stack offset that depends on the presence of the other parameter. I don't know if the error code needs to be popped before iret.

bjorn3 (Aug 27 2026 at 09:28):

Also if the error code parameter is present, the stack needs to be re-aligned.

Chris Fallin (Aug 27 2026 at 15:48):

All of this seems a bit fidgety and I think we'd want to see a diff. Another callconv that just means "everything is saved" is pretty easy; but special parameters with special meanings, and special stack alignment concerns (especially dynamic re-alignment), are extremely annoying and might push this over into "maintenance burden and impact on rest of code that does not pay its way".

FWIW while Cranelift strives to support everything it can all other things being equal, its philosophy toward edge-case features is pretty different than e.g. LLVM because we're such a small team. So "blocker for kernel writing its interrupt handlers directly in CLIF" may not be enough. Most production kernels hand-write their interrupt entry sequences in assembly anyway (and then call into whatever higher-level language handler using the standard calling convention)

Last updated: Aug 30 2026 at 09:07 UTC