Tracking issue for the `x86-interrupt` calling convention #40180

phil-opp · 2017-03-01T18:04:22Z

Overview

Tracking issue for the x86-interrupt calling convention, which was added in PR #39832. The feature gate name is abi_x86_interrupt. This feature will not be considered for stabilization without an RFC.

The x86-interrupt calling convention can be used for defining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses iret instead of ret for returning and ensures that all registers are restored to their original values.

Usage

extern "x86-interrupt" fn handler(stack_frame: ExceptionStackFrame) {…}

for interrupts and exceptions without error code and

extern "x86-interrupt" fn handler_with_err_code(stack_frame: ExceptionStackFrame,
                                                error_code: u64) {…}

for exceptions that push an error code (e.g., page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt.

For more details see the LLVM PR, and the corresponding proposal.

Known issues

An earlier version of this description stated that the ExceptionStackFrame is passed by reference (instead of by value). This used to work on older LLVM version, but no longer works on LLVM 12. See Tracking issue for the x86-interrupt calling convention #40180 (comment) for more details.
LLVM doesn't preserve MMX and x87 floating point registers across interrupts. This issue was reported in __attribute__((interrupt)) trashes MMX registers llvm/llvm-project#26785.
(fixed) x86-interrupt calling convention leads to wrong error code in debug mode (x86-interrupt calling convention leads to wrong error code in debug mode #57270)
F-abi_x86_interrupt currently shows:

64-bit

The x86_64 automatically aligns the stack on a 16-byte boundary when an interrupts occurs in 64-bit mode. However, the CPU pushes an 8-byte error code for some exceptions, which destroys the 16-byte alignment. At the moment, LLVM doesn't handle this case correctly and always assumes a 16-byte alignment. This leads to alignment issues on targets with SSE support, since LLVM uses misaligned movaps instructions for saving the xmm registers. This issue is tracked as bug 26413.

A fix for this problem was submitted in D30049 and merged in rL299383.
LLVM always tries to backup the xmm registers on 64-bit platforms even if the target doesn't support SSE. This leads to invalid opcode exceptions whenever an interrupt handler is invoked.

The fix was merged to LLVM trunk in rL295347. Backported in x86 interrupt calling convention: only save xmm registers if the target supports SSE llvm#63.
__attribute__((interrupt)) Handlers Dangerously Out of Spec on x86-64 llvm/llvm-project#41189

32-bit

In 32-bit mode, the CPU performs no stack alignment on interrupts. Thus, the interrupt handler should perform a dynamic stack alignment (i.e. and esp, 16). However, LLVM doesn't do that at the moment, which might lead to alignment errors, especially for targets with SSE support. This issue is tracked in interrupt handler calls functions with misaligned stack llvm/llvm-project#26851.

The text was updated successfully, but these errors were encountered:

Tracking issue: rust-lang#40180 This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ``` extern "x86-interrupt" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ``` extern "x86-interrupt" fn page_fault_handler(stack_frame: &ExceptionStackFrame, error_code: u64) {…} ``` for exceptions that push an error code (e.g., page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html

@tari

…ention, r=nagisa Add support for the x86-interrupt calling convention This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ```rust extern "x86-interrupt" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ```rust extern "x86-interrupt" fn handler_with_err_code(stack_frame: &ExceptionStackFrame, error_code: u64) {…} ``` for exceptions that push an error code (e.g., page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html It is also possible to implement interrupt handlers on x86 through [naked functions](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md). In fact, almost all existing Rust OS projects for x86 use naked functions for this, including [Redox](https://github.com/redox-os/kernel/blob/b9793deb59c7650f0805dea96adb6b773ad99336/arch/x86_64/src/lib.rs#L109-L147), [IntermezzOS](https://github.com/intermezzOS/kernel/blob/f959cc18c78b1ba153f3ff7039d9ecc07f397628/interrupts/src/lib.rs#L28-L72), and [blog_os](https://github.com/phil-opp/blog_os/blob/844d739379ffdea6a7ede88365ec6e21a725bbf5/src/interrupts/mod.rs#L49-L64). So support for the `x86-interrupt` calling convention isn't absolutely needed. However, it has a number of benefits to naked functions: - **No inline assembly needed**: [Inline assembly](https://doc.rust-lang.org/book/inline-assembly.html) is highly unstable and dangerous. It's pretty easy to mess things up. Also, it uses an arcane syntax and requires that the programmer knows x86 assembly. - **Higher performance**: A naked wrapper function always saves _all_ registers before calling the Rust function. This isn't needed for a compiler supported calling convention, since the compiler knows which registers are clobbered by the interrupt handler. Thus, only these registers need to be saved and restored. - **Safer interfaces**: We can write a `set_handler` function that takes a `extern "x86-interrupt" fn(&ExceptionStackFrame)` and the compiler ensures that we always use the right function type for all handler functions. This isn't possible with the `#[naked]` attribute. - **More convenient**: Instead of writing [tons of assembly boilerplate](https://github.com/redox-os/kernel/blob/b9793deb59c7650f0805dea96adb6b773ad99336/arch/x86_64/src/lib.rs#L109-L147) and desperately trying to improve things [through macros](https://github.com/phil-opp/blog_os/blob/844d739379ffdea6a7ede88365ec6e21a725bbf5/src/interrupts/mod.rs#L17-L92), we can just write [code like this](https://github.com/phil-opp/blog_os/blob/e6a61f9507a4c4fef6fb4e3474bc596391bc97d2/src/interrupts/mod.rs#L85-L89). - **Naked functions are unreliable**: It is allowed to use Rust code inside a naked function, which sometimes works and sometimes not. For example, [calling a function](https://github.com/redox-os/kernel/blob/b9793deb59c7650f0805dea96adb6b773ad99336/arch/x86_64/src/lib.rs#L132) through Rust code seems to work fine without function prologue, but [code declaring a variable](https://is.gd/NQYXqE) silently adds a prologue even though the function is naked (look at the generated assembly, there is a `movl` instruction before the `nop`). **Edit**: See the [tracking issue](rust-lang#40180) for an updated list of issues. Unfortunately, the implementation of the `x86-interrupt` calling convention in LLVM has some issues that make it unsuitable for 64-bit kernels at the moment: - LLVM always tries to backup the `xmm` registers on 64-bit platforms even if the target doesn't support SSE. This leads to invalid opcode exceptions whenever an interrupt handler is invoked. I submitted a fix to LLVM in [D29959](https://reviews.llvm.org/D29959). The fix is really small (<10 lines), so maybe we could backport it to [Rust's LLVM fork](https://github.com/rust-lang/llvm)?. **Edit**: The fix was merged to LLVM trunk in [rL295347](https://reviews.llvm.org/rL295347). Backported in rust-lang/llvm#63. - On targets with SSE support, LLVM uses the `movaps` instruction for saving the `xmm` registers, which requires an alignment of 16. For handlers with error codes, however, the stack alignment is only 8, so a alignment exception occurs. This issue is tracked in [bug 26413](https://bugs.llvm.org/show_bug.cgi?id=26413). ~~Unfortunately, I don't know enough about LLVM to fix this.~~ **Edit**: Fix submitted in [D30049](https://reviews.llvm.org/D30049). This PR adds experimental support for this calling convention under the `abi_x86_interrupt` feature gate. The implementation is very similar to rust-lang#38465 and was surprisingly simple :). There is no accepted RFC for this change. In fact, the [RFC for interrupt calling convention](rust-lang/rfcs#1275) from 2015 was closed in favor of naked functions. However, the reactions to the recent [PR](rust-lang#38465) for a MSP430 interrupt calling convention were [in favor of experimental interrupt ABIs](rust-lang#38465 (comment)). - [x] Add compile-fail tests for the feature gate. - [x] Create tracking issue for the `abi_x86_interrupt` feature (and link it in code). **Edit**: Tracking issue: rust-lang#40180 - [x] Backport [rL295347](https://reviews.llvm.org/rL295347) to Rust's LLVM fork. **Edit**: Done in rust-lang/llvm#63 @tari @steveklabnik @jackpot51 @ticki @hawkw @thepowersgang, you might be interested in this.

@tari

…ention, r=nagisa Add support for the x86-interrupt calling convention This calling convention can be used for definining interrupt handlers on 32-bit and 64-bit x86 targets. The compiler then uses `iret` instead of `ret` for returning and ensures that all registers are restored to their original values. Usage: ```rust extern "x86-interrupt" fn handler(stack_frame: &ExceptionStackFrame) {…} ``` for interrupts and exceptions without error code and ```rust extern "x86-interrupt" fn handler_with_err_code(stack_frame: &ExceptionStackFrame, error_code: u64) {…} ``` for exceptions that push an error code (e.g., page faults or general protection faults). The programmer must ensure that the correct version is used for each interrupt. For more details see the [LLVM PR][1] and the corresponding [proposal][2]. [1]: https://reviews.llvm.org/D15567 [2]: http://lists.llvm.org/pipermail/cfe-dev/2015-September/045171.html It is also possible to implement interrupt handlers on x86 through [naked functions](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md). In fact, almost all existing Rust OS projects for x86 use naked functions for this, including [Redox](https://github.com/redox-os/kernel/blob/b9793deb59c7650f0805dea96adb6b773ad99336/arch/x86_64/src/lib.rs#L109-L147), [IntermezzOS](https://github.com/intermezzOS/kernel/blob/f959cc18c78b1ba153f3ff7039d9ecc07f397628/interrupts/src/lib.rs#L28-L72), and [blog_os](https://github.com/phil-opp/blog_os/blob/844d739379ffdea6a7ede88365ec6e21a725bbf5/src/interrupts/mod.rs#L49-L64). So support for the `x86-interrupt` calling convention isn't absolutely needed. However, it has a number of benefits to naked functions: - **No inline assembly needed**: [Inline assembly](https://doc.rust-lang.org/book/inline-assembly.html) is highly unstable and dangerous. It's pretty easy to mess things up. Also, it uses an arcane syntax and requires that the programmer knows x86 assembly. - **Higher performance**: A naked wrapper function always saves _all_ registers before calling the Rust function. This isn't needed for a compiler supported calling convention, since the compiler knows which registers are clobbered by the interrupt handler. Thus, only these registers need to be saved and restored. - **Safer interfaces**: We can write a `set_handler` function that takes a `extern "x86-interrupt" fn(&ExceptionStackFrame)` and the compiler ensures that we always use the right function type for all handler functions. This isn't possible with the `#[naked]` attribute. - **More convenient**: Instead of writing [tons of assembly boilerplate](https://github.com/redox-os/kernel/blob/b9793deb59c7650f0805dea96adb6b773ad99336/arch/x86_64/src/lib.rs#L109-L147) and desperately trying to improve things [through macros](https://github.com/phil-opp/blog_os/blob/844d739379ffdea6a7ede88365ec6e21a725bbf5/src/interrupts/mod.rs#L17-L92), we can just write [code like this](https://github.com/phil-opp/blog_os/blob/e6a61f9507a4c4fef6fb4e3474bc596391bc97d2/src/interrupts/mod.rs#L85-L89). - **Naked functions are unreliable**: It is allowed to use Rust code inside a naked function, which sometimes works and sometimes not. For example, [calling a function](https://github.com/redox-os/kernel/blob/b9793deb59c7650f0805dea96adb6b773ad99336/arch/x86_64/src/lib.rs#L132) through Rust code seems to work fine without function prologue, but [code declaring a variable](https://is.gd/NQYXqE) silently adds a prologue even though the function is naked (look at the generated assembly, there is a `movl` instruction before the `nop`). **Edit**: See the [tracking issue](rust-lang#40180) for an updated list of issues. Unfortunately, the implementation of the `x86-interrupt` calling convention in LLVM has some issues that make it unsuitable for 64-bit kernels at the moment: - LLVM always tries to backup the `xmm` registers on 64-bit platforms even if the target doesn't support SSE. This leads to invalid opcode exceptions whenever an interrupt handler is invoked. I submitted a fix to LLVM in [D29959](https://reviews.llvm.org/D29959). The fix is really small (<10 lines), so maybe we could backport it to [Rust's LLVM fork](https://github.com/rust-lang/llvm)?. **Edit**: The fix was merged to LLVM trunk in [rL295347](https://reviews.llvm.org/rL295347). Backported in rust-lang/llvm#63. - On targets with SSE support, LLVM uses the `movaps` instruction for saving the `xmm` registers, which requires an alignment of 16. For handlers with error codes, however, the stack alignment is only 8, so a alignment exception occurs. This issue is tracked in [bug 26413](https://bugs.llvm.org/show_bug.cgi?id=26413). ~~Unfortunately, I don't know enough about LLVM to fix this.~~ **Edit**: Fix submitted in [D30049](https://reviews.llvm.org/D30049). This PR adds experimental support for this calling convention under the `abi_x86_interrupt` feature gate. The implementation is very similar to rust-lang#38465 and was surprisingly simple :). There is no accepted RFC for this change. In fact, the [RFC for interrupt calling convention](rust-lang/rfcs#1275) from 2015 was closed in favor of naked functions. However, the reactions to the recent [PR](rust-lang#38465) for a MSP430 interrupt calling convention were [in favor of experimental interrupt ABIs](rust-lang#38465 (comment)). - [x] Add compile-fail tests for the feature gate. - [x] Create tracking issue for the `abi_x86_interrupt` feature (and link it in code). **Edit**: Tracking issue: rust-lang#40180 - [x] Backport [rL295347](https://reviews.llvm.org/rL295347) to Rust's LLVM fork. **Edit**: Done in rust-lang/llvm#63 @tari @steveklabnik @jackpot51 @ticki @hawkw @thepowersgang, you might be interested in this.

rexlunae · 2017-03-30T02:51:23Z

If we're going to have an x86-interrupt abi, would it also make sense to have an x86-syscall? Or x86-sysenter?

kyrias · 2017-04-17T17:11:24Z

(D30049 was merged to LLVM trunk on the 3rd of April, for the record.)

phil-opp · 2017-04-19T14:08:23Z

@kyrias Thanks for the hint, I updated the issue text. I'll try to create a backport PR in the next few days.

steveklabnik · 2019-03-12T17:48:28Z

Triage: not aware of any movement stabilizing this.

Personal note: this is one of my favorite rust features :)

kyrias · 2019-07-16T12:34:56Z

Both of the 64-bit issues have long since been fixed, and Rust's minimum LLVM is newer than the fix, so it's just the MMX/x87 floating point and 32-bit issues remaining, which appear to have been untouched since 2017.

phil-opp · 2019-07-16T12:47:36Z

@kyrias I updated the issue description. I also added #57270, which will be hopefully fixed soon with the LLVM 9 upgrade.

josephlr · 2020-09-30T06:59:30Z

@phil-opp I think this issue can be updated to cross off #57270

On the x87/MMX issue, we should just mandate that to use the interrupt ABI, you have to build the code with target-features of -x87 and -mmx (-mmx could be a default now that MMX support is gone from Rust). It looks like LLVM and GCC just never intend to support saving/restoring the MMX/x87 registers, so it's probably not worth trying to make it work (as nobody should be using those features anyway.

We may also want to similarly disallow all SSE code in interrupt handlers (GCC bans SSE code, Clang allows it), as that might make it easier to make sure we are doing the right thing.

phil-opp · 2020-09-30T07:02:26Z

@phil-opp I think this issue can be updated to cross off #57270

Done!

mark-i-m · 2020-11-06T03:04:23Z

Just came across the following from a conference paper, and thought I would quote here as a data point:

We implement the low-level interrupt entry and exit code in assembly. While Rust provides support for the x86-interrupt function ABI (a way to write a Rust function that takes the x86 interrupt stack frame as an argument), in practice, it is not useful as we need the ability to interpose on the entry and exit from the interrupt, for example, to save all CPU registers.

(section 4.1 of https://www.usenix.org/system/files/osdi20-narayanan_vikram.pdf)

repnop · 2021-04-06T16:46:09Z

After discussing this on the Rust Community Server #os-dev channel with some folks (cc @Soveu @asquared31415), and checking out the LLVM patch that includes the ABI, it seems like taking the struct by-reference is incorrect and leads to undefined behavior (as seen in rust-osdev/x86_64#240). This seems to have worked previously, but I suspect the upgrade to LLVM 12 may have "fixed" the behavior. (edit: asquared tested both 2021-03-03 and 2021-03-05 nightly releases, both by-value and by-ref work on the former, but by-ref breaks on the latter, which I think pretty much confirms the LLVM 12 upgrade fixed the behavior)

The patch to LLVM includes the following code, suggesting that the very first parameter should always be by-value and never by-reference.

if (F.getCallingConv() == CallingConv::X86_INTR) {
    // IA Interrupt passes frame (1st parameter) by value in the stack.
    if (Idx == 1)
        Flags.setByVal();
}

Soveu · 2021-04-06T16:50:10Z

By the way, if the function signature contains more than 2 arguments LLVM crashes with

LLVM ERROR: unsupported x86 interrupt prototype

phil-opp · 2021-04-06T18:20:45Z

@repnop Thanks a lot for investigating this! I'll look into it and update the description of this issue if I can confirm that it works with a by-value parameter. Given that the Rust implementation just sets the LLVM calling convention, this shouldn't require any changes on the Rust side to fix it. We should adjust the x86_64 crate though.

To prevent issues like this (and wrong number of arguments errors), we should probably introduce some kind of lint that checks the function signature when the x86-interrupt calling convention is used. It's probably difficult to check the layout of the ExceptionStackFrame struct in detail, but verifying the number of parameters and the correct argument types (struct and optional u64) should be possible. I don't have any experience with creating lints though, so I'm not sure about the details.

Soveu · 2021-04-06T18:41:02Z

Also, we have found with @asquared31415 that using the second argument can cause stack corruption, because LLVM does not check if there is an error code and just pops unconditionally

Andy-Python-Programmer · 2021-04-08T23:50:23Z

I'll look into it and update the description of this issue if I can confirm that it works with a by-value parameter. Given that the Rust implementation just sets the LLVM calling convention, this shouldn't require any changes on the Rust side to fix it. We should adjust the x86_64 crate though.

It does work by-value parameter!

Everything now seems to be correct. Eg the stack segment is (16) => 0x10 which is valid

Thanks @repnop and @phil-opp!

Andy-Python-Programmer · 2021-04-09T02:34:45Z

Discovered something more:
As we are writing to 0xdeadbeaf the stack segment should be 0x00. For example this is a right interrupt stack:

(Picture from OS Phillip's Blog)
As you can see the image below its 0x10.

Soveu · 2021-04-09T07:11:34Z

Shouldn't 0x0 segment be null descriptor? (which iirc is invalid, stack segment should be a 64bit data segment)

Since LLVM 12 (rust-lang/rust#84230) ExceptionStackFrame has to be taken by value. See rust-lang/rust#40180 (comment).

joshtriplett · 2022-01-26T19:10:54Z

We discussed this in today's @rust-lang/lang meeting.

We agree that this needs an RFC. Not specifically for x86-interrupt, but an "target-specific interrupt calling conventions" RFC. Once that RFC goes in, new target-specific interrupt calling conventions would just need a patch to the ABI section of the reference, ideally documenting the calling convention.

Would someone involved in this thread be up for writing that RFC?

@phil-opp Would you be willing to write that RFC?

We'd also appreciate an update to the API evolution RFC, to note that target-specific calling conventions are only as stable as the targets they're supported on; if we remove a target (for which we have guidelines and process in the target tier policy), removing its associated target-specific calling conventions is not a breaking change.

josephlr · 2022-01-27T11:33:46Z

I think this is a problem that needs to be solved before x86-interrupt can be stabilized. To give an idea of the severity of this issue, let's say a user-space program executes the instruction int 14 (which invokes the page fault exception handler). In this case no error code is pushed since it's just a software interrupt, not a real page fault. The problem is that the page fault exception handler is still expecting an error code, which isn't there, resulting in stack corruption, with everything off by 8 bytes.

The problem described here is exactly why you must have DPL == 0 in any IDT entry for an exception (i.e. vectors 0 though 31). That way, a usermode process cannot corrupt the kernel stack or (more generally) trigger the kernel's interrupt handling code in unexpected ways. With this setup, if usermode executes int 14, you just get a #GP.

As it stands currently, having an IDT entry directly reference an x86-interrupt function that takes an error code is unsound. You would instead need to use a trampoline function to work around the issue as in @Soveu's solution above.

I don't think this is true. It's the calling code's responsibility to make sure that each interrupt handler invocation matches its function signature, including:

If there is an error code pushed or not
The InterruptStackFrame having the correct size/alignment

While the calling convention doesn't provide these protections itself (as its just abound declaring functions), things like the x86_64 crate can help here. It's also worth noting that the "check sp alignment and conditionally push values" trampoline code linked above is not what Linux does. Based on the IDT vector, you should always know if an error code is present or not.

In short, I don't think any of the above issues should block stabilization. Of course, the LLVM crashes, error messages, and known issues probably need to be addressed before stabilization.

phil-opp · 2022-01-27T14:50:46Z

@joshtriplett Yes, I'm happy to work on this! I will create a rough draft and then open a pre-rfc thread on internals to discuss the details.

mikeleany · 2022-01-27T14:50:58Z

I think this is a problem that needs to be solved before x86-interrupt can be stabilized. To give an idea of the severity of this issue, let's say a user-space program executes the instruction int 14 (which invokes the page fault exception handler). In this case no error code is pushed since it's just a software interrupt, not a real page fault. The problem is that the page fault exception handler is still expecting an error code, which isn't there, resulting in stack corruption, with everything off by 8 bytes.

The problem described here is exactly why you must have DPL == 0 in any IDT entry for an exception (i.e. vectors 0 though 31). That way, a usermode process cannot corrupt the kernel stack or (more generally) trigger the kernel's interrupt handling code in unexpected ways. With this setup, if usermode executes int 14, you just get a #GP.

Thank you for the correction. DPL == 0 does indeed prevent the issue of user-level code corrupting the kernel stack in this way.

In short, I don't think any of the above issues should block stabilization. Of course, the LLVM crashes, error messages, and known issues probably need to be addressed before stabilization.

Given that my concern about user-level code corrupting the kernel stack was incorrect, I agree.

josephlr · 2022-02-03T19:26:56Z

Should we change the bug references above to point to:

As the LLVM project has moved to GitHub Issues.

phil-opp · 2022-02-05T15:35:20Z

Should we change the bug references above to point to:

Thanks for the suggestion! I updated/added the references you mentioned.

phil-opp · 2022-02-20T19:41:55Z

I created a Pre-RFC for initial feedback at https://internals.rust-lang.org/t/pre-rfc-interrupt-calling-conventions/16182. Please let me know what you think!

chorman0773 · 2022-04-09T04:22:48Z

Note: This is unsound on 32-bit x86 (Protected mode) if llvm expects the esp/ss field.

When the processor is in legacy mode, esp and ss are pushed by the interrupt (and popped by iret) only if the interrupt crosses privilege levels (gate.RPL<CPL for interrupt, retcs.RPL>CPL for iret)

workingjubilee · 2024-10-14T00:45:39Z

If these are supposed to work like normal Rust functions they probably shouldn't ICE on ZST arguments? #126418

phil-opp mentioned this issue Mar 1, 2017

Add support for the x86-interrupt calling convention #39832

Merged

3 tasks

brson added the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Mar 1, 2017

steveklabnik mentioned this issue Mar 1, 2017

add abi_x86_interrupt to the unstable book #40181

Closed

Mark-Simulacrum added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Jul 22, 2017

phil-opp mentioned this issue Jan 2, 2019

x86-interrupt calling convention leads to wrong error code in debug mode #57270

Closed

jonas-schievink added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Mar 27, 2020

mkroening mentioned this issue May 21, 2021

ExceptionStackFrame in interrupts contains gibberish hermit-os/kernel#195

Closed

stlankes added a commit to RWTH-OS/eduOS-rs that referenced this issue Dec 8, 2021

Take ExceptionStackFrame by value

6fa0be8

Since LLVM 12 (rust-lang/rust#84230) ExceptionStackFrame has to be taken by value. See rust-lang/rust#40180 (comment).

stlankes added a commit to RWTH-OS/eduOS-rs that referenced this issue Dec 8, 2021

Take ExceptionStackFrame by value

2595648

Since LLVM 12 (rust-lang/rust#84230) ExceptionStackFrame has to be taken by value. See rust-lang/rust#40180 (comment).

stlankes added a commit to RWTH-OS/eduOS-rs that referenced this issue Dec 8, 2021

Take ExceptionStackFrame by value

93e92c3

Since LLVM 12 (rust-lang/rust#84230) ExceptionStackFrame has to be taken by value. See rust-lang/rust#40180 (comment).

stlankes added a commit to RWTH-OS/eduOS-rs that referenced this issue Dec 8, 2021

Take ExceptionStackFrame by value

39f136b

Since LLVM 12 (rust-lang/rust#84230) ExceptionStackFrame has to be taken by value. See rust-lang/rust#40180 (comment).

stlankes added a commit to RWTH-OS/eduOS-rs that referenced this issue Dec 8, 2021

Take ExceptionStackFrame by value

4918d6e

Since LLVM 12 (rust-lang/rust#84230) ExceptionStackFrame has to be taken by value. See rust-lang/rust#40180 (comment).

joshtriplett added the S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. label Jan 26, 2022

joshtriplett mentioned this issue Jan 26, 2022

Tracking issue for the msp430-interrupt calling convention/ABI #38487

Open

This comment has been minimized.

Sign in to view

phil-opp mentioned this issue Mar 23, 2022

RFC: Interrupt calling conventions rust-lang/rfcs#3246

Open

andrisaar mentioned this issue May 25, 2022

Start populating the IDT and handle double faults. project-oak/oak#2893

Merged

joshtriplett mentioned this issue Jul 13, 2022

Tracking Issue for the avr-interrupt/avr-non-blocking-interrupt calling convention/ABI #69664

Open

3 tasks

arkivm mentioned this issue Dec 22, 2022

Moving from rustup/nightlies to standard rust AMDESE/linux-svsm#28

Open

cuviper mentioned this issue Apr 5, 2023

x86-interrupt calling convention with error code is broken on x86_64-unknown-none #109918

Closed

sethp mentioned this issue May 23, 2023

Tracking Issue for riscv-interrupt-{m,s} ABIs #111889

Open

3 tasks

workingjubilee added the F-abi_x86_interrupt label Oct 13, 2024

MajoraSans mentioned this issue Oct 21, 2024

Tracking issue for experimental features in 1.49 implemented in gccrs Rust-GCC/gccrs#3210

Open

85 tasks

This was referenced Nov 10, 2024

extern "x86-interrupt" fn allows absurd signatures #132835

Open

Directly calling "x86-interrupt" fn should be invalid #132834

Open

workingjubilee added the A-hardware-interrupts Area: Code for handling the "interrupt ABI" of various processors label Nov 10, 2024

workingjubilee mentioned this issue Nov 10, 2024

All interrupt ABIs should enforce either () or ! as return types #132841

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for the `x86-interrupt` calling convention #40180

Tracking issue for the `x86-interrupt` calling convention #40180

phil-opp commented Mar 1, 2017 •

edited by workingjubilee

Loading

rexlunae commented Mar 30, 2017

kyrias commented Apr 17, 2017

phil-opp commented Apr 19, 2017

steveklabnik commented Mar 12, 2019

kyrias commented Jul 16, 2019

phil-opp commented Jul 16, 2019

josephlr commented Sep 30, 2020

phil-opp commented Sep 30, 2020

mark-i-m commented Nov 6, 2020

repnop commented Apr 6, 2021 •

edited

Loading

Soveu commented Apr 6, 2021

phil-opp commented Apr 6, 2021

Soveu commented Apr 6, 2021

Andy-Python-Programmer commented Apr 8, 2021 •

edited

Loading

Andy-Python-Programmer commented Apr 9, 2021 •

edited

Loading

Soveu commented Apr 9, 2021 •

edited

Loading

joshtriplett commented Jan 26, 2022 •

edited

Loading

This comment has been minimized.

josephlr commented Jan 27, 2022 •

edited

Loading

phil-opp commented Jan 27, 2022

mikeleany commented Jan 27, 2022

josephlr commented Feb 3, 2022

phil-opp commented Feb 5, 2022

phil-opp commented Feb 20, 2022

chorman0773 commented Apr 9, 2022

workingjubilee commented Oct 14, 2024

Tracking issue for the x86-interrupt calling convention #40180

Tracking issue for the x86-interrupt calling convention #40180

Comments

phil-opp commented Mar 1, 2017 • edited by workingjubilee Loading

Overview

Usage

Known issues

64-bit

32-bit

rexlunae commented Mar 30, 2017

kyrias commented Apr 17, 2017

phil-opp commented Apr 19, 2017

steveklabnik commented Mar 12, 2019

kyrias commented Jul 16, 2019

phil-opp commented Jul 16, 2019

josephlr commented Sep 30, 2020

phil-opp commented Sep 30, 2020

mark-i-m commented Nov 6, 2020

repnop commented Apr 6, 2021 • edited Loading

Soveu commented Apr 6, 2021

phil-opp commented Apr 6, 2021

Soveu commented Apr 6, 2021

Andy-Python-Programmer commented Apr 8, 2021 • edited Loading

Andy-Python-Programmer commented Apr 9, 2021 • edited Loading

Soveu commented Apr 9, 2021 • edited Loading

joshtriplett commented Jan 26, 2022 • edited Loading

This comment has been minimized.

josephlr commented Jan 27, 2022 • edited Loading

phil-opp commented Jan 27, 2022

mikeleany commented Jan 27, 2022

josephlr commented Feb 3, 2022

phil-opp commented Feb 5, 2022

phil-opp commented Feb 20, 2022

chorman0773 commented Apr 9, 2022

workingjubilee commented Oct 14, 2024

Tracking issue for the `x86-interrupt` calling convention #40180

Tracking issue for the `x86-interrupt` calling convention #40180

phil-opp commented Mar 1, 2017 •

edited by workingjubilee

Loading

repnop commented Apr 6, 2021 •

edited

Loading

Andy-Python-Programmer commented Apr 8, 2021 •

edited

Loading

Andy-Python-Programmer commented Apr 9, 2021 •

edited

Loading

Soveu commented Apr 9, 2021 •

edited

Loading

joshtriplett commented Jan 26, 2022 •

edited

Loading

josephlr commented Jan 27, 2022 •

edited

Loading