Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directly calling extern "riscv-interrupt-{m,s}" fn... compiles? #132836

Open
workingjubilee opened this issue Nov 10, 2024 · 6 comments
Open

Directly calling extern "riscv-interrupt-{m,s}" fn... compiles? #132836

workingjubilee opened this issue Nov 10, 2024 · 6 comments
Labels
A-ABI Area: Concerning the application binary interface (ABI) A-hardware-interrupts Area: Code for handling the "interrupt ABI" of various processors A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. O-AVR Target: AVR processors (ATtiny, ATmega, etc.) O-riscv Target: RISC-V architecture T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@workingjubilee
Copy link
Member

workingjubilee commented Nov 10, 2024

I tried this code with rustc --target riscv64gc-unknown-linux-gnu rust_code.rs:

#![feature(abi_riscv_interrupt)]
pub extern "riscv-interrupt-m" fn interrupt_machine() {}

pub extern "riscv-interrupt-s" fn interrupt_supervisor() {}

pub fn main() {
    interrupt_machine();
    interrupt_supervisor();
}

I expected to see this happen: rustc or LLVM reject the direct call.

Instead, this happened:

...wait, why does it compile? This doesn't seem like it should compile...

Meta

rustc --version --verbose:

rustc 1.84.0-nightly (a0d98ff0e 2024-10-31)
binary: rustc
commit-hash: a0d98ff0e5b6e1f2c63fd26f68484792621b235c
commit-date: 2024-10-31
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.

@rustbot label: +A-hardware-interrupts +A-LLVM +O-riscv +A-ABI +T-compiler

Related Issues

@workingjubilee workingjubilee added the C-bug Category: This is a bug. label Nov 10, 2024
@rustbot rustbot added needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. A-ABI Area: Concerning the application binary interface (ABI) A-hardware-interrupts Area: Code for handling the "interrupt ABI" of various processors A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. O-riscv Target: RISC-V architecture T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 10, 2024
@workingjubilee
Copy link
Member Author

Filed upstream as llvm/llvm-project#115640

@workingjubilee
Copy link
Member Author

#![feature(no_core, lang_items)]
#![feature(abi_avr_interrupt)]
#![no_core]
#[lang = "sized"]
trait Sized {}

pub extern "avr-interrupt" fn avr_interrupt() {}

pub fn call() {
    avr_interrupt();
}

Also compiles...? cc @Patryk27 is this sensical?

@rustbot label: +O-AVR

@rustbot rustbot added the O-AVR Target: AVR processors (ATtiny, ATmega, etc.) label Nov 10, 2024
@workingjubilee workingjubilee removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 10, 2024
@workingjubilee
Copy link
Member Author

AVR variant filed upstream as llvm/llvm-project#115641

@workingjubilee workingjubilee changed the title Directly calling a extern "riscv-interrupt-{m,s}" fn... compiles? Directly calling extern "riscv-interrupt-{m,s}" fn... compiles? Nov 10, 2024
@Patryk27
Copy link
Contributor

Hmm, I would've thought that interrupt handlers must be unsafe (in which case it's your fault you're calling an unsafe function like that) 🤔

But yeah, extra validation on rustc's and LLVM's side won't hurt.

@workingjubilee
Copy link
Member Author

It seems they need not be unsafe either!

I don't think it makes much sense for them to be unsafe, as there's nothing intrinsically unsafe about an interrupt handler, just... everything it then does probably requires unsafe. But you kind of have to be callable at any time, you know? By nature of being an interrupt handler.

@workingjubilee
Copy link
Member Author

That said, I have no intrinsic objection to adopting such a limitation, just... not enforced today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ABI Area: Concerning the application binary interface (ABI) A-hardware-interrupts Area: Code for handling the "interrupt ABI" of various processors A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. O-AVR Target: AVR processors (ATtiny, ATmega, etc.) O-riscv Target: RISC-V architecture T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants