OSDev.org

Hey again guys,

Well I decided to redo some of the HAL interface and the kernel but, now when I try to use interrupts it fails. With a triple fault, not sure why. Would someone please take a look at the code? To see if you guys can figure it out. I've been doing this for a few days and I must have made a stupid mistake without spotting it. Not sure which file that mistake could be in though. I would like to know why it keeps triple faulting when I use interrupts though.

Project Link boot32-barebones (Development Branch) : https://github.com/psimonson/boot32-bar ... evelopment

PS: The development branch is the one I'm working on. Also everything I modified is in the kernel directory, somewhere in there is where the problem is.

Thanks in advance,
Philip

"Here's my repository, pls debug"? That's new levels of not SSCCE...

Solar wrote:"Here's my repository, pls debug"? That's new levels of not SSCCE...

Hahaha! I wish I had thought of that... would have have saved me loads of time!

Seriously though, my source code is available for anyone who wants to have a go debugging my mess

So, what debugging hae you done so far?

(Hint - single-stepping under a debugger can be very instructive.)

Are there any tutorials on how to debug a kernel in QEMU or could you help guide me if you've got the time? Because so far the only debugging I've done is on normal applications. Not sure how to debug a kernel in QEMU. Please help and thanks.

Your issue is that you have no assembly in your kernel or HAL at all.

rizxt wrote:Your issue is that you have no assembly in your kernel or HAL at all.

Did you miss the various bits of inline assembly code? What is missing that you think is necessary?

Literally, the Wiki states that you can't make an interrupt handler in C using just inline assembly.

I can't find that statement, but it's obviously false. The only thing I can find on the subject shows you precisely how you could use inline assembler for this purpose or, even simpler, how to use "__attribute__((interrupt))".

It's true that the OP's interrupt handlers won't work correctly as they are written, because they don't include an "iret" instruction, but as the end with an infinite loop this would not cause the triple fault.

iansjack stupidly wrote: I can't find that statement

https://wiki.osdev.org/Interrupt_Servic ... he_Problem

I still can't find that statement, just an example of how not to do it.

It results in a triple fault because ebp is pushed but never popped... CPU pops important registers back from the stack and since the stack is corrupted it faults.

So, as shown further down in that article, you either use inline assembler to insert the correct instructions or you use the directive. It's not the way I would do it, as I'm not a fan of inline assembler, but it can be done.

In this case, as the interrupt routine never tried to return, it's unlikely to be the cause of the triple fault.

As Ianjacks point out there is the __attribute__((interrupt)) that was introduced in GCC 7+. Unfortunately it has some restrictions that may be a problem for some kind of interrupts. If you want reliable access to the state of *all* the registers as they were before the interrupt was called - you can't. There is a mechanism that does work on old and new GCC and that is to write the entry point to an interrupt in pure basic inline assembly at global scope and then have that call into C code. That can be found here: https://stackoverflow.com/a/43311525/3857942 . You can then create C macros to generate these stubs for a large number of entries for ISRs and IRQs. Although the sample code doesn't pass a parameter to the handlers that can be added. That code in the answer was meant as a simplification and meant to show how this can be done.