Interrupts in a simple x86 kernel aren't working; triple faulting.

[adhamAhdamAdam]

Hello!
I've been recently starting to learn OS development and started taking Poncho's YouTube tutorials. When I implement the IDT, even going to past commits, I still get a triple fault.

IDT.cpp

Code: Select all

#pragma once
#include "TypeDefs.cpp"
#include "drivers/IO.cpp"
#include "drivers/TextPrint.cpp"
#include "Sets/KBSCodesS1.cpp"


struct IDT64 {
    uint_16 offset_low;
    uint_16 selector;
    uint_8 ist;
    uint_8 types_attr;
    uint_16 offset_mid;
    uint_32 offset_high;
    uint_32 zero;
};

extern IDT64 _idt[256];
extern uint_64 isr1;
extern "C" void LoadIDT();

void MakeIDTEntry(uint_64 handler, uint_16 index, uint_8 selector, uint_8 types_attr){
    uint_64 off1 = 0x000000000000FFFF;
    uint_64 off2 = 0x00000000FFFF0000;
    uint_64 off3 = 0xFFFFFFFF00000000;
    _idt[index].zero = 0;
    _idt[index].offset_low = (uint_16)(((uint_64) & handler & off1));
    _idt[index].offset_mid = (uint_16)(((uint_64) & handler & off2) >> 16);
    _idt[index].offset_high = (uint_32)(((uint_64) & handler & off3) >> 32);
    _idt[index].ist = 0;
    _idt[index].selector = selector;
    _idt[index].types_attr = types_attr;


}

void InitializeIDT(){
    MakeIDTEntry(isr1, 1, 0x08, 0x8e);

    outb(0x21, 0xfd);
    outb(0xA1, 0xff);
    LoadIDT();
    
}

extern "C" void isr1_handler(){
    uint_8 scanCode = inb(0x60);
    PrintChar(KBSet1::ScanCodeLookupTable[scanCode]),
    outb(0x20, 0x20);
    outb(0xA0, 0x20);
}

When I run my compile script, nothing happens, but when a keypress occurs, it triple faults and displays the splash icon again.
Most wikis say that interrupt 33 is for the keyboard, but I think based on my

Code: Select all

RemapPic();

function that the tutorial offset it differently.

My assembly code is as here:

Code: Select all

[extern _idt]

idtDescriptor:
    dw 4095
    dq _idt

%macro PUSHALL 0
    push rax
    ; etc
%endmacro

%macro POPALL 0
    pop r11
    ; etc
%endmacro

[extern isr1_handler]
isr1:
    PUSHALL
    call isr1_handler
    POPALL
    iretq
    GLOBAL isr1

LoadIDT:
    lidt [idtDescriptor]
    sti
    ret
    GLOBAL LoadIDT

I've been rewriting the code more than once, so I appreciate any help, and tell me if code is needed.

[nullplan]

The handler address you write into the GDT is the address of the "handler" variable, not the handler itself. That is probably not what you want.

[adhamAhdamAdam]

So I should remove the &'s? Tried like this before with a function, but still nothing.
It's more specifically triple faulting on keypress.

[Octocontrabass]

I've been recently starting to learn OS development and started taking Poncho's YouTube tutorials.

The vast majority of OSdev tutorials are broken in some way or another. Don't assume any of the code shown in the tutorial is correct, even if it worked for the author.

When I implement the IDT, even going to past commits, I still get a triple fault.

Have you checked QEMU's interrupt log ("-d int") to see which exceptions cause the triple fault? It's also a good idea to set up exception handlers before you worry about handling IRQs.

Code: Select all

#include "TypeDefs.cpp"

You should learn C++ before you try to write an OS in C++, just like Poncho should have learned C++ before writing an OSdev tutorial in C++. You should use freestanding headers like <cstdint> instead of redefining things yourself.

Code: Select all

    MakeIDTEntry(isr1, 1, 0x08, 0x8e);

Most wikis say that interrupt 33 is for the keyboard, but I think based on my

Code: Select all

RemapPic();

function that the tutorial offset it differently.

Most examples use interrupt vector 33 for the keyboard because interrupt vectors below 32 are reserved for CPU exceptions.

[adhamAhdamAdam]

OK!
I fixed the error anyways
On the types part
Like now I implemented SSE, and it isn't working.
Can you explain how it works with him and mine doesn't?

[Octocontrabass]

Like now I implemented SSE, and it isn't working.

What is it doing instead of working? I can't help you find the problem without more information.

Can you explain how it works with him and mine doesn't?

His code unintentionally relies on specific behavior of his compiler or virtual machine. Since you aren't using exactly the same compiler and virtual machine, his code doesn't work for you. If he ever continues working on his OS, he'll probably update his compiler and virtual machine, and then his code won't work for him either.