OSDev.org

Im having a problem when i try to handle interrupt request i tried it on virtualbox it gives me VINF_EM_TRIPLE_FAULT error and terminates the vbox. i tried it on my physical machine but it terminates when i try to start it. im using C++ and following a tutorial on youtube i double checked the code but i couldn't find the problem. Can someone help me please?

gdt.cpp



interrupts.cpp


kernel.cpp

There's more information in the VirtualBox log that might help you (or us!) track down what's actually going wrong, but I'm not sure if VirtualBox has the same level of debugging output as QEMU or Bochs.


Most tutorials have mistakes. Youtube tutorials are especially bad because it's difficult for the author to go back and correct the mistakes.

i tried it on QEMU but it goes for endless loop and reboots everytime. at first i thought it's because of virtualbox but i guess somethings wrong in my code but when i check the tutorial it's exact same code. However tutor's code is working. I cloned his project and tried.It worked on my machine aswell.

This looks like some variation of the Wyoos (Write Your Own Operating System) tutorial. It is suggested you modified an existing tutorial. I guess my first question is, did the code you start with work before you made changes to it?

Is it possible to put the code you are using and the Makefile and or build scripts onto something like Github so we can see everything and build it? It is possible the problems are beyond the code you show. I do notice one of the inline assembly needs a "memory" clobber although I suspect there is something else going on.

Add "-d int" and "-no-reboot" to your QEMU command line to stop the endless reboot loop and get a log that will give you lots of information to help find the problem.


There must be some difference somewhere. Could it be a difference in the part of the code you haven't shown us yet?

Yes my code was running normally before i added interrupt descriptor table. Heres my project https://github.com/eraykaradag/CernOS .

A couple of strange things in the GDT. Your GDT structure is 9 bytes in size rather than 8 bytes. You have this for SegmentDescriptor:When it should be:I've removed flags in your GlobalDescriptorTable constructor and you seem to have the size and the address mixed up (and the inline assembly is a problematic). A serious problem is that after the LGDT instruction they never loaded the segment registers with proper values. The way they did it may work by chance on some environments and not others. You had:It should probably look something like:Not sure why the tutorial author limited the segments to 64*1024*1024 (64MiB). You might want to consider 4UL*1024*1024*1024-1 for the full 4GiB address space.

Getting the GDT right is the important first step since interrupts will inevitably attempt to restore segment registers especially CS on an IRET as well as DS, ES, SS, GS, FS. If the GDT is wrong then you will get an exception when reloading the segment registers with a new selector.

Edit: An additional issue with your code - you will likely want to ensure you aren't generating 32-bit position independent code (PIC). To get that working requires extra effort so I recommend compiling your C/C++ files with -fno-PIC. Depending on the default options of your compiler you could be generating PIC and you may not have the glue in place to support it, and that could cause unexpected behaviour in your program.

I wrote some other posts on this forum about the WYOOS tutorial here and here. The second link has some additional information about problems in the Exception Handlers since some exceptions have error codes pushed by the processor and others don't.

One other problem you may encounter is that you aren't currently sending EOI (end of interrupts) to the PIC(s) so you may get one or two interrupts and then no further interrupts will be received. The original WYOOS code handled it but your interrupt handlers don't do anything.

Huge thanks. I was about to give up. This really made me motivated thanks man.

No problem. I have made a ton of edits to that original comment in the past couple hours with some changed code (especially around the LGDT instruction and provided links to a couple of other posts I made about the WYOOS code. You might want to scroll back and look at the latest version of my comment.

Yes i have seen it already thank you for your effort it's really means to me.

You're telling the compiler that the inline assembly will only access one byte. The input operand needs to have the correct size, not just the correct address. A packed struct is usually a good choice:



The ADD instruction modifies flags, so you need a "cc" clobber here too.


If you use a reasonable cross-compiler (such as i686-elf-g++), it will generate position-dependent code by default. Getting consistent behavior in different build environments is just one of the reasons why you should use a cross-compiler.

The reason for the "memory" clobber is to deal with the issue of the structure. The compilers will realize that data into memory with that clobber. The other option was to actually specify an array of a certain number of bytes.

Technically given the nature of what reloading all the segments with new selectors can do (but not in this case since one is moving from a flat model to a flat model) `memory` clobber would be preferable for a generic use case. However one could have got away in this case with removing `memory` clobber and treating the memory structure as an array of 6 bytes withEven better would have been to create a struct (even a temporary one) for the GDT record to make this cleaner as you did in your code. I have seen this design pattern for LGDT in the past to ensure that the `base` in the GDTR is on a 4 byte aligned address although I'm unsure where this came from. I'm unaware of a requirement for LGDT to do this or that there is something gained from it.

`cc` clobber isn't used on the x86/x86-64 targets (on these targets it is assumed that the conditional flags are always clobbered). It has no effect (it could in the future, but unlikely since it would break a lot of code). Other targets like ARM are a different story.

Removing `volatile` from that asm assembly statement though would have been correct as well.

I didn't give a complete run down on all the other odd choices the tutorial author made. in gdt.cpp he could have included cstddef and used `offsetof` and it was very peculiar that he had structures in the GDT with member variables but then chose to modify the class data as a byte array. Things like not ensuring proper alignment when the interrupt handler code is called is problematic and there was no `cld` to ensure forward movement as required by the ABI. I also mention a host of other problems with the exception handlers. I have not gone through the WYOOS tutorial with a fine tooth comb but there are definitely a lot of things that can go wrong and trip up a person who may not know what is going on and how to fix things. Not sure anyone has started an errata sheet for that tutorial like we did with James Molloy.

I thought it was for the segment register loads, since those read and (sometimes) write the descriptors in the GDT.


It's a good reminder for when you're writing assembly on non-x86 targets.


It's a good reminder for when you're writing assembly that has output operands.

This is a good point and one that would apply to this code. What I have done in my code in the past is to also pass a dummy memory constraint as an input/output operand that is the entire GDT. While the inline assembly doesn't actually do anything with the constraint it does force the compiler to commit the GDT to memory before the inline assembly code is emitted and reread it after if need be. In general it is a lot easier to just pass the `memory` clobber. Since this code is only executed once during initialization, the performance penalty of the `memory` clobber for that inline assembly is going to be marginal.

I'd usually tell people that for things like this it is often easier to code the LGDT and the reloading of registers as a separate assembly language function. Then you aren't concerned with all the nuances of inline assembly. If you don't know what you are doing it can bite you later on in unexpected ways.

The solution you gave me fixed my problem i can get interrupts from hardware but the next problem is i can't get interrupt from keyboard and i couldn't find the problem. Could you look at my code again?
I pushed new codes to github. https://github.com/eraykaradag/CernOS