Help with 32-bit IDT handlers

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
icr09
Posts: 2
Joined: Fri Oct 02, 2026 3:06 pm

Help with 32-bit IDT handlers

Post by icr09 »

Hi, I'm new to OSdev. I'm not quite sure how to navigate the site, so I apologize if I've posted this in the wrong place. Lately, I've been struggling to find information on how to create handlers—such as one for division-by-zero errors. Could someone give me a tip on where to find this info, or perhaps how to write a simple handler? I've checked various sources, but I haven't been able to find a clear explanation or any relevant results in my searches.
Octocontrabass
Member
Member
Posts: 6270
Joined: Mon Mar 25, 2013 7:01 pm

Re: Help with 32-bit IDT handlers

Post by Octocontrabass »

This is a really vague question. Which part, specifically, are you having trouble with? Creating the IDT structure in memory and telling the CPU to use it? Writing assembly stubs to fix up the ABI and call a handler written in a higher-level language? Deciding what you want the handler to do when it's called?
icr09
Posts: 2
Joined: Fri Oct 02, 2026 3:06 pm

Re: Help with 32-bit IDT handlers

Post by icr09 »

Specifically regarding assembly, how do I retrieve the error code generated by the CPU? That is the specific part I'm asking about.
Octocontrabass
Member
Member
Posts: 6270
Joined: Mon Mar 25, 2013 7:01 pm

Re: Help with 32-bit IDT handlers

Post by Octocontrabass »

Exceptions that produce error codes push it onto the stack, right after the return address. You access it the same way you access anything else on the stack.

Since the return address and error code are already on the stack, one common strategy is to push the rest of the CPU state that needs to be saved onto the stack as well, and then pass (a pointer to) the whole structure as an argument to the higher-level language handler. You'll want all of that information when you're debugging exceptions anyway, so it makes sense to put it all in the same place.
Post Reply