GCC编译x86-64中断服务例程参数报错及InterruptFrame定义问题

1 编译报错的两个核心诱因 #

• 诱因1：中断处理函数声明为了非静态类成员函数
  非静态类成员函数会被编译器隐式插入this指针作为第一个参数，你代码中声明的InterruptFrame* frame实际会被编译器识别为第二个参数，完全打乱了中断处理函数要求的参数顺序，所以所有ISR都会触发参数不匹配的报错。必须将ISR声明为类的静态成员函数，或直接定义为全局函数。
• 诱因2：错误码参数类型不匹配
  x86-64架构下GCC要求带错误码的异常处理函数第二个参数必须为unsigned long int，虽然unsigned long long int在x86-64平台也是64位宽度，但二者属于不同的类型签名，编译时的强制校验无法通过，直接替换类型即可。

2 x86-64架构下InterruptFrame结构体的正确定义 #

CPU在触发中断/异常时会按照固定顺序自动向栈中压入寄存器内容，InterruptFrame需要严格匹配这个压栈顺序，正确定义如下：

struct InterruptFrame {
    UINT64 rip;    // 触发中断时的指令地址
    UINT64 cs;     // 代码段选择子
    UINT64 rflags; // 标志寄存器
    UINT64 rsp;    // 触发中断时的栈指针
    UINT64 ss;     // 栈段选择子
} __attribute__((packed)); // 禁用编译器结构体对齐，避免偏移错误

如果发生特权级切换（比如用户态触发中断进入内核态），CPU会自动压入完整的上述5个寄存器；如果是同特权级触发中断，CPU不会压入rsp和ss，但GCC的interrupt属性会自动处理这种差异，你统一使用该结构体即可，无需额外适配。带错误码的异常中错误码由CPU压在rip的更低地址位置，会被GCC自动识别为第二个参数，不需要写入InterruptFrame定义。

3 修正后的代码示例 #

struct InterruptFrame {
    UINT64 rip;
    UINT64 cs;
    UINT64 rflags;
    UINT64 rsp;
    UINT64 ss;
} __attribute__((packed));

class IDT {
public:
    // 声明为静态成员函数，消除隐式this指针
    // 除零错误（无错误码）
    __attribute__((interrupt)) static void isr0(InterruptFrame* frame);
    // 页错误（带错误码）
    __attribute__((interrupt)) static void isr14(InterruptFrame* frame, unsigned long errorCode);
};

__attribute__((interrupt)) void IDT::isr0(InterruptFrame* frame) {
    asm volatile("hlt");
}

__attribute__((interrupt)) void IDT::isr14(InterruptFrame* frame, unsigned long errorCode) {
    asm volatile("hlt");
}

原来的编译指令无需修改即可正常编译。

内容的提问来源于stack exchange，提问作者user123