Registering random interrupt handlers in the IDT causes exception 0xb. about x86_64 HOT 7 CLOSED

Hmm, what is the error code of the exception? It should be the selector of the present entry.

from x86_64.

The error code as given by the function argument is 0x802.

from x86_64.

Ok, I think I found the problem. The IDT struct looks like this:

pub struct Idt {
    pub divide_by_zero: IdtEntry<HandlerFunc>,
    pub debug: IdtEntry<HandlerFunc>,
    […]
    pub interrupts: [IdtEntry<HandlerFunc>; 224],
    // some fields omitted
}

So we have special cases for the first 32 interrupts, which means that the interrupts field starts at index 32. So try doing idt.interrupts[0x80 - 32].set_handler_fn(syscall::syscall_handler) instead.

This seems like a huge pitfall, so I think we should look for a better solution, or at least document it explicitly.

from x86_64.

This works, thanks. Weird that this has to be done though. Maybe we could modify the Index implementations to account for this? As a side note: In my kernel I have remapped the PICs to 0x20 and 0x28, and have no trouble thus registering the timer and keyboard IRQs to the first and second indices of the interrupts field. I'm assuming this bug won't affect IRQs given that the PIC sends interrupts to the CPU separately.

from x86_64.

This works, thanks.

Great!

Weird that this has to be done though. Maybe we could modify the Index implementations to account for this?

The problem is that we want to special case interrupts 0-32, since they have fixed meaning and some of them have an additional error code (which means they have a different type). If we would change the index implementation of the interrupts field, then we would have to issue a runtime panic for indices smaller than 32, which is not ideal either (but maybe better?).

As a side note: In my kernel I have remapped the PICs to 0x20 and 0x28, and have no trouble thus registering the timer and keyboard IRQs to the first and second indices of the interrupts field. I'm assuming this bug won't affect IRQs given that the PIC sends interrupts to the CPU separately.

This "affects" neither software nor hardware interrupts, it's just a different numbering convention. So your int 0x80 goes to the 0x80s entry in the IDT, which is the 0x80-32s entry in the interrupts array. Equally, your timer interrupt goes to entry 0x20 (due to the PIC remapping), which is the 0x20-32=0s entry in the interrupt array.

from x86_64.

Ah I see, makes sense. Thanks.

from x86_64.

Note to future readers:

The interrupts field on the Idt struct is no longer public, and an Index and IndexMut impl was added for Idt. This means idt.interrupts[0x80 - 32].set_handler_fn(syscall::syscall_handler) should now be expressed as idt[0x80].set_handler_fn(syscall::syscall_handler).

from x86_64.