Home/ Questions/Q 7586105
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T19:20:34+00:00

I’ve read (and studied) about Interrupt Handling. What I always fail to understand, is

  • 0

I’ve read (and studied) about Interrupt Handling.
What I always fail to understand, is how do we know where to return to (PC / IP) from the Interrupt Handler.
As I understand it:

  1. An Interrupt is caused by a device (say the keyboard)
  2. The relevant handler is called – under the running process. That is, no context switch to the OS is performed.
  3. The Interrupt Handler finishes, and passes control back to the running application.

The process depicted above, which is my understanding of Interrupt Handling, takes place within the current running process’ context. So it’s akin to a method call, rather than to a context switch.
However, being that we didn’t actually make the CALL to the Interrupt Handler, we didn’t have a chance to push the current IP to the stack.
So how do we know where to jump back from an Interrupt. I’m confused.

Would appreciate any explanation, including one-liners that simply point to a good pdf/ppt addressing this question specifically.
[I’m generally referring to above process under Linux and C code – but all good answers are welcomed]

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    When an interrupt is triggered, the CPU pushes several registers onto the stack, including the instruction pointer (EIP) of the code that was executing before the interrupt. You can put iret and the end of your ISR to pop these values, and restore EIP (as well as CS, EFLAGS, SS and ESP).

    By the way, interrupts aren’t necessarily triggered by devices. In Linux and DOS, user space programs use interrupts (via int) to make system calls. Some kernel code uses interrupts, for example intentionally triple faulting in order to force a shutdown.

    • 0