Attribute for processor interrupt handlers

[flysand7]

Abstract

Whenever an interrupt is issued, for example an IO interrupt when you press a mouse, or a user application page faults, the x86 processor would index into Interrupt Descriptor Table, get the address of the Interrupt Service Routine (ISR) and call it.

The ISRs are very different from normal functions in the structure, since upon calling that routine, more information is put on the stack. If a normal procedure call only pushes the return address, the ISR call (via INT or hardware interrupt) pushes far pointer to the original stack, (E/R)FLAGS register, and the far pointer to the code that was executing before the interrupt was issued. Therefore to return from an ISR a different instruction is required -- IRET (IRETD/IRETQ).

Most interrupt service routines also save the general-purpose registers on the stack so that after the ISR returns, the program can continue to run normally. Some ISRs also clear the direction flag DF.

Implementing ISR using inline assembly is considered to be a bad practice. An example from OSdev wiki:

void interrupt_handler() {
    __asm__("pushad");
    /* do something */
    __asm__("popad; iret");
}

This cannot work. The compiler doesn't understand what is going on. It doesn't understand that the registers and stack are required to be preserved between the asm statements; the optimizer will likely corrupt the function. Additionally, the compiler adds stack handling code before and after your function, which together with the iret results in assembly code resembling this:

push   ebp
mov    ebp, esp
sub    esp, <...>

pushad
# C code comes here
popad
iret

# 'leave' if you use local variables, 'pop ebp' otherwise.
leave
ret

An obvious observation is that this function corrupts the stack, since iret is executed first, returning from the interrupt handler with the wrong stack and leave is never executed.

Therefore the compiler needs to provide a way to write ISRs. Of course, programmers can resort to assembly when needed, but this requires 2 function calls (one ISR, another is the call of high-level handler) for each interrupt.

There are two alternatives to how ISR programming support can be added to a programming language:

• Naked functions: prologue, epilogue and ret instructions are not inserted, instead the user can define their own prologue and epilogue using inline assembly. This is the approach used by MSVC
• Interrupt attribute: the function has a special calling convention, which only allows for one or two parameters: interrupt stack frame pointer and, optionally, error code. This is the approach used in clang and gcc.

Since I don't know any other use for the naked function and interrupt attribute would be in any way simpler for a kernel programmer to use, I advocate using that.

Overview of how interrupts work

Whenever an interrupt is initiated, either by hardware or by a program calling INT instruction, the processor switches to the kernel privilege level and calls an interrupt service routine.

The stack at that point looks like this:

Offset	Thing
rsp+40	SS
rsp+32	RSP
rsp+16	RFLAGS
rsp+8	CS
rsp+0	RIP

I will not explain the meaning of those fields, but the processor needs them in order to return back to the original program after interrupt has finished servicing.

Some interrupts also push the error code onto the stack, in which case the stack has different offsets:

Offset	Thing
rsp+48	SS
rsp+40	RSP
rsp+32	RFLAGS
rsp+16	CS
rsp+8	RIP
rsp+0	Error code

So there are two kinds of ISRs -- those that take the error code and those that do not. IRET instruction automatically clears this stack, so no additional care is needed. Note, however that for some interrupts the ISR wants to know the values of certain fields from this stack. e.g. if a program has crashed, sometimes it's useful that the OS knows the failing address.

Proposed syntax and mechanism

So the ISR will be declared as a normal function with interrupt attribute.

@(interrupt)
my_handler::proc(stack_frame: rawptr) {}

// or

@(interrupt)
my_handler::proc(stack_frame: rawptr, error_code: u64) {}

In the first version, the stack_frame would be the value of RSP at the time the function is called. The user will declare their own version of the stack frame struct.

In the second version, the stack_frame would be rsp+8, and error_code would be a value of a qword located at the address rsp. Since error_code is typically only used for reading it doesn't matter where the actual variable is located.

In addition to that @(interrupt) functions need to ensure the following:

• Context is not passed to these functions
• Before the code in the body is executed, the general-purpose registers are saved
• Before the code in the body is executed, the DF flag is cleared
• Before the return instruction, the general-purpose registers are restored
• The function returns using IRET instruction

Note that only the general-purpose registers are saved. If any other features of the processor are used within the ISR (SSE, AVX, MMX, ...) the registers corresponding to those features need to be saved as well. This is lots of overhead usually for no benefit. So the next item is:

• No SSE, AVX, MMX, ...