OSDev.org

Hi all

Now I've got 64 bit long mode working I am trying to set up software interrupts before I enable the hardware ones. The table seems to be working well but the issue seems to be when I use a software interrupt for example int 33, the iretq sends the kernel into somewhere it shouldn't. The registers before the iretq are



The RSP before the interrupt is 0xffffc0. The stack looks like



Which appears OK as the 0x1000437 is the correct return address. The code is



The ISR prints a message and then should return to the jmp $ line but instead returns to some other part of memory. I've read the articles and double checked the tables but everything looks OK. Any ideas?

Bipman

You said after the iretq it jumps to "somewhere in memory", where exactly? Did you try debugging (single stepping), what happens? The state you copied here, is it after the code returns from your popraxrdi but before the iretq? If not, that would likely be the most useful, single stepping makes it easy to capture the state at that point.

Is it possible that you cause some exception and don't have an exception handler?

You were right, it was another interrupt. I created a GPF handler plus system error handler and it was the GPF that fired. I'm now trying to find out what caused the GPF but not sure how I find out.

Bipman

Check the stack, what did the #GP push there? There should be CS:EIP for the instruction that caused the #GP as well as an error code, either it's zero or a segment selector.. You can disassemble your binary and check which instruction exactly caused the #GP. If you can't solve it, copy some of the disassembly with the contents of the stack (the #GP pushed error code and CS:EIP)..

From Wiki



Finally, I would recommend creating a single exception/interrupt handler that does nothing but print something like "unhandler interrupt/exception" and then halts and in the IDT put all the entries you have pointing to that. That way you always catch them and you'll know that something went wrong (ie. you didn't expect it). Later when you have the time just add valid exception handlers and leave the "generic" one handling the rest, hopefully at some point you have handlers for everything.

You might also want to improve on that a bit by making it print relevant regs, maybe the interrupt/exception number that occurred, possible error code, etc. If you don't print that stuff then everything that goes to the generic handler is indistinguishable, but even still at least you know something went wrong and can keep adding handlers one by one. Choice is yours =)

Note: I intentionally included interrupts and exceptions, I'm guessing quite a few have been bit early in their development by unintentionally enabling interrupts and then PIT or something else generates interrupt and everything just goes crazy for no apparent reason. Related to this last part it's worth remembering that until you re-map the PIC you have no (easy) way of knowing whether something is caused by an IRQ or exception as by default they overlap..

Thanks, I'll give it a go. I re-mapped the PIC first and then enabled interrupts with the obvious outcome of faults everywhere so turned them off and went back to software interrupts first.

Bipman

The GPF routine returned the IRETQ as the offending instruction which is a bit weird as I've tried with and without popping the error code just in case and it still causes a GPF even though the return address on the stack is correct. I'll keep looking .....

Bipman

What do you mean by "with and without popping the error code"? Can you elaborate it a bit?

Two things you could try is to either check your "pusha" and "popa" to see that they are proper or simply remove everything from your "Default_Int" except for iretq and see what happens.. single-stepping with debugger is quite useful.

Also can you provide disassembly of your binary? Just to make sure everything is as it should be, you can use objdump for that:
objdump -D -M intel kernel.bin
Obviously replace kernel.bin with the name of your file..

Can you also provide stack contents right when you enter the #GP (set breakpoint to it and dump stack with debugger)?

I meant trying to take the error code off the stack before the iretq. I tried the iretq on it's own without the rest of the code for that routine and still got a GPF. I've attached the stack at entry to routine and also the code, the fun starts at line 82.

Bipman

I've solved it now. It had to be something on the stack that was being popped that was causing the GPF. Turned out it was the SS register which I set to 0 and it worked which is strange. I thought as I was in 64 bit long mode that the segment registers did not matter? I know it puts the segment registers in in case you want to return to 32 bit mode but surely with an iretq it can tell?

Bipman

As you have discovered, segment registers still have a role to play in long mode. Null selectors are not a good idea.

Null selectors are fine for everything except SS and CS. CS obviously needs to be loaded with a long mode segment. While SS base address and limit is ignored its privilege level is still checked.