Hi All,
well been playing around with asm for a while and simple protected mode demos.... I can get into protected mode..set things going etc....and call a basic interrupt.
Now it was all working great, till I just noticed, that when I call a simple interrupt (e.g. divide by 0) it doesn't seem to return from it... just seems to halt
Now if I use Int 0x0 to force the interrupt it seems to return okay.
But!, when I use a real divide by zero operation, it seems to never return :-/
; Force a call to interrupt 0!
Int 0x0 ; We call our interrupt 0 subroutine
; Do a divide by 0 error, so we force a call to our interrupt 0
; mov eax, 0
; mov ebx, 0
; div ebx ; eax divided by ebx, and stored back in eax
Is there a flag or something I need to reset in my interrupt routine?
Thanks,
Ben
not returning from an interupt (iret)? no idea why!
Re:not returning from an interupt (iret)? no idea why!
Hi,
For Intel CPUs there's "traps" and "faults", where "divide error" is classed as a fault. The practical difference is that the return CS:EIP for a trap points to the instruction after the one that caused the exception, while for a fault the return CS:EIP points to the instruction that caused the exception.
This means your exception handler does return - it returns to the instruction that caused the divide error, which causes another exception, which returns to the faulty instruction, which causes another exception, which... Um, it'd do a lot of returning
.
You're not meant to return though - typically an OS would kill the process/thread, dump core, panic or display a pretty blue screen (BSOD). The reason for this is that the faulty code is faulty, and if your exception handler pretends that it's not faulty the problems can get much worse later. For example, imagine it's a hard disk driver calculating the cylinder, head and sector to write to, and you pretend the faulty division worked.
Cheers,
Brendan
For Intel CPUs there's "traps" and "faults", where "divide error" is classed as a fault. The practical difference is that the return CS:EIP for a trap points to the instruction after the one that caused the exception, while for a fault the return CS:EIP points to the instruction that caused the exception.
This means your exception handler does return - it returns to the instruction that caused the divide error, which causes another exception, which returns to the faulty instruction, which causes another exception, which... Um, it'd do a lot of returning
.You're not meant to return though - typically an OS would kill the process/thread, dump core, panic or display a pretty blue screen (BSOD). The reason for this is that the faulty code is faulty, and if your exception handler pretends that it's not faulty the problems can get much worse later. For example, imagine it's a hard disk driver calculating the cylinder, head and sector to write to, and you pretend the faulty division worked.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Ben_3D
Re:not returning from an interupt (iret)? no idea why!
Thanks again Brendan,
really didn't know it stored the actual address that caused the interrupt on the stack...but it does make sense.
I would have thought that if I used int 0x0 to cause the interrupt, wouldn't it still always return to int 0x0 and call itself as well?.... I'm assuming that if you force an interrupt, using int, it saves the following address
Thanks again Brendan
Ben
really didn't know it stored the actual address that caused the interrupt on the stack...but it does make sense.
I would have thought that if I used int 0x0 to cause the interrupt, wouldn't it still always return to int 0x0 and call itself as well?.... I'm assuming that if you force an interrupt, using int, it saves the following address
Thanks again Brendan
Ben
-
mystran
Re:not returning from an interupt (iret)? no idea why!
Don't assume anything, instead, check the documentation for the exception type: everything is either fault, trap or abort.
For fault, you can try to correct the situation, and resume. Example of this is page fault.
For trap, the trap is called after the instruction is executed, and you can then log it (?) or whatever, and continue normally if you want.
For an abort, no particular saving point is guaranteed. My copy of The Documentation, tells that exactly double fault and machine check are aborts.
Now, as for (normal) software interrupts, they are interrupts, and don't really cause an exception (unless GPF occurs, which is another story). Therefore, they always function like traps, and they also don't push any error codes.
The trap/fault/abort has really nothing to do with the interrupt vector called, but instead just the type of exception that occurs. In case of the debug exception, you actually have to handle both traps and faults in the same routine.
For fault, you can try to correct the situation, and resume. Example of this is page fault.
For trap, the trap is called after the instruction is executed, and you can then log it (?) or whatever, and continue normally if you want.
For an abort, no particular saving point is guaranteed. My copy of The Documentation, tells that exactly double fault and machine check are aborts.
Now, as for (normal) software interrupts, they are interrupts, and don't really cause an exception (unless GPF occurs, which is another story). Therefore, they always function like traps, and they also don't push any error codes.
The trap/fault/abort has really nothing to do with the interrupt vector called, but instead just the type of exception that occurs. In case of the debug exception, you actually have to handle both traps and faults in the same routine.