Page 1 of 1
A. Frounze's PMode Tutorials. JMP to the beginnin of the GPF handler after IRETD. Why?
Posted: Tue Mar 03, 2026 4:10 pm
by 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
Re: A. Frounze's PMode Tutorials. JMP to the beginnin of the GPF handler after IRETD. Why?
Posted: Tue Mar 03, 2026 5:14 pm
by 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?
Re: A. Frounze's PMode Tutorials. JMP to the beginnin of the GPF handler after IRETD. Why?
Posted: Tue Mar 03, 2026 5:35 pm
by 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.
Re: A. Frounze's PMode Tutorials. JMP to the beginnin of the GPF handler after IRETD. Why?
Posted: Tue Mar 03, 2026 5:58 pm
by Octocontrabass
Intel SDM wrote: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.
Re: A. Frounze's PMode Tutorials. JMP to the beginnin of the GPF handler after IRETD. Why?
Posted: Thu Mar 05, 2026 5:59 pm
by 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.
Re: A. Frounze's PMode Tutorials. JMP to the beginnin of the GPF handler after IRETD. Why?
Posted: Fri Mar 06, 2026 10:31 am
by Octocontrabass
Ralph26 wrote: ↑Thu Mar 05, 2026 5:59 pmThe 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.
Ralph26 wrote: ↑Thu Mar 05, 2026 5:59 pmNow that JMP after IRETD can be removed.
What happens if there's another #GP?
Re: A. Frounze's PMode Tutorials. JMP to the beginnin of the GPF handler after IRETD. Why?
Posted: Mon Mar 09, 2026 5:59 pm
by 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.