Hacker News new | ask | show | jobs
by kibwen 1569 days ago
And support for the `#[naked]` attribute will likely be stabilizing within the next few months (source: I'm getting sponsored to work on it), allowing one to write functions that have precise control over the stack, which is useful for interrupt handlers.
1 comments
eddyb 1569 days ago
Don't you want "interrupt ABIs" for that specific usecase?

IIRC `#[naked]` are only really guaranteed to allow inline assembly, so it's like defining a function in `global_asm!` except for monomorphization and generally interfacing better with the rest of the language.

link
kibwen 1569 days ago
I'm not aware of any proposal for interrupt ABIs, but in the meantime naked functions essentially allow you to create ad-hoc interruput ABIs. Do you have a link?
link
steveklabnik 1569 days ago
https://github.com/rust-lang/rust/issues/40180 was the first one; and Phil has created a pre-RFC a few days ago: https://internals.rust-lang.org/t/pre-rfc-interrupt-calling-...

(That said you're right that naked functions still have a place for doing this, I can't imagine the compiler would grow stable support for every random ABI someone could come up with. But for more well-known ones it's a nice thing.)

link
eddyb 1568 days ago
It's a shame LLVM isn't more explicit about calling conventions (especially since the front-end has to lower most of the platform-specific C ABI details, short of the exact list of registers or stack offsets, into LLVM IR anyway).

(if it was more expressive, we could have e.g. specifiers similar to inline `asm!`, but on a function signature, to fully describe its call ABI)

In the meanwhile, I agree - if you need some entry-point to have a custom ABI (especially if you need it parameterized through generics), `#[naked]` + inline `asm!` is the only viable option for now.

Especially with const generics, you can do some cool stuff to make very compact trampolines that e.g. embed immediates directly into instructions (though it's sad that `const` operands in inline `asm!` aren't stable yet).

But for interrupt ABIs I would hope that LLVM can fully support them and avoid any inefficiencies that "whole body is one inline `asm!`" could create by blocking LLVM from doing optimizations, clever register allocation, etc.

(that is, they let the user control when they do something special with inline `asm!` vs regular code that LLVM understands)

link