A. Frounze's PMode Tutorials. JMP to the beginnin of the GPF handler after IRETD. Why?

[Ralph26]

In the A. Frounze's PMode tutorials, TUT14, file ISR_WRAP.ASM, you can see this code for the GPF handler:

Code: Select all

_gpf_task_wrapper:
        call    _gpf_handler            ; call actual ISR code
        add     sp, 4                   ; pop off error code
        iretd
        jmp short _gpf_task_wrapper     ; if we forget about this stuff,
                                        ; we won't be able to run this task
                                        ; again anymore

The GPF vector 13 in the IDT is a task gate.
Can anyone explain why that JMP after IRETD?

I am writing similar code and, effectively, without that JMP the code execution continues after IRETD.

Thanks

[Octocontrabass]

It has something to do with hardware task switching.

Hardware task switching is awful and obsolete and nobody should use it. Why do you want to use hardware task switching?

[Ralph26]

I am doing some experiments with task gates.
I have a GPF handler managed via task gate in the IDT and I came across this strange behavior.
Without that JMP, the handler does not return to the interrupted task.

[Octocontrabass]

If the NT flag is set, the IRET instruction performs a task switch (return) from a nested task (a task called with a CALL instruction, an interrupt, or an exception) back to the calling or interrupted task. The updated state of the task executing the IRET instruction is saved in its TSS. If the task is re-entered later, the code that follows the IRET instruction is executed.

[Ralph26]

I have solved updating the return CS:EIP field in the TSS of the interrupted task.
The GPF handler increments return EIP by 2 in order to jump the faulting instruction.

Now that JMP after IRETD can be removed.

[Octocontrabass]

The GPF handler increments return EIP by 2 in order to jump the faulting instruction.

That seems like it would only work if you already know ahead of time that the faulting instruction is 2 bytes long and safe to skip.

Now that JMP after IRETD can be removed.

What happens if there's another #GP?

[Ralph26]

Yes, it is a specific exception (MOV TSS selector to a segment register), with a two bytes opcode.

OK, I am reading the Intel 80386 Software Writers Guide and things are clearer now.
IRETD with NT=1 saves the ISR state in its TSS with CS:EIP that points to the instruction
that follows the same IRETD, then switches to the interrupted task.
The next exception begins execution after IRETD, so that JMP is required.

Thanks for your help.