Help with 32-bit IDT handlers
Help with 32-bit IDT handlers
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

- Posts: 6270
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Help with 32-bit IDT handlers
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?
Re: Help with 32-bit IDT handlers
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

- Posts: 6270
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Help with 32-bit IDT handlers
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.
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.