x86 Exceptions help

[Coconut9]

I cannot find the reason of some Exception Handlers.
Example:
"into" generate int 0x04 if overflow flag set
But why some program have this instruction and what i need to insert into handler?
Any program can just use "jo" instruction and do what it want of overflow flag is set,right?


Another example:
"int 0x03" (or "int3") is debug breakpoint and i need to stop the process until ........ ?

Anyone how knows?

[mallard]

The "INTO" instruction is just a way for a program to manually signal an error. You should probably treat #OF (INT 4) just like any other non-recoverable program error (e.g. by terminating it). It's of very limited usefulness and apparently not valid at all in long (64-bit) mode.

#BP (INT 3) is used to implement software breakpoints (useful since x86 only has 4 hardware breakpoints). Generally, your kernel would suspend the program and notify a debugger application somehow. The debugger would then have some way of notifying the kernel when/if it wants the program resumed.

Neither of these will occur at all unless your code specifically uses them, so it's perfectly fine to treat them both as fatal program errors to begin with.

[Coconut9]

The "INTO" instruction is just a way for a program to manually signal an error. You should probably treat #OF (INT 4) just like any other non-recoverable program error (e.g. by terminating it). It's of very limited usefulness and apparently not valid at all in long (64-bit) mode.

#BP (INT 3) is used to implement software breakpoints (useful since x86 only has 4 hardware breakpoints). Generally, your kernel would suspend the program and notify a debugger application somehow. The debugger would then have some way of notifying the kernel when/if it wants the program resumed.

Neither of these will occur at all unless your code specifically uses them, so it's perfectly fine to treat them both as fatal program errors to begin with.

Thanks a lot, I can understand if the the int's 0x08,0x09 fired i must terminate the program but can you tell me also what Ι suppose to do with int's 0x01,0x02,0x05,0x07,0x10-0x13 and when the 0x16-0x19 and 0x20-0x31 int's will fire?

[iansjack]

You are not supposed to do anything particular with exceptions - you choose what is the most appropriate action, in your operating system, to handle them. In some cases it may be to terminate the program, or even the operating system; in others it may be as simple as creating a new mapping for a virtual address.

Other interrupts will be fired at the times you have programmed them to. Normally this means associating a particular device, or devices, with an interrupt so that the interrupt happens when the device sends an interrupt. Interrupts can also be the result of a software instruction.

I think you need to read the Intel Programmer's Manuals.

[Brendan]

Hi,

Thanks a lot, I can understand if the the int's 0x08,0x09 fired i must terminate the program but can you tell me also what Ι suppose to do with int's 0x01,0x02,0x05,0x07,0x10-0x13 and when the 0x16-0x19 and 0x20-0x31 int's will fire?

The Intel (and AMD) manuals clearly say what each exception is, what triggers it, etc.

For some, they're purely to support features used for normal operation (e.g. debug exception used to support software debuggers, alignment check used for finding performance problems).

For some, the exception might or might not be "normal trickery" (e.g. a page fault that tells the OS something needs to be loaded from swap space, an undefined opcode exception telling the OS that it needs to emulate an instruction that the CPU doesn't support, device not available exception used as part of a "delayed FPU/MMX/SSE/AVX state saving scheme" designed to improve task switch performance, etc). For these cases, the OS has to figure out if it's an error condition or if it's being asked to do something (and do it).

For some it's always an error, but depending on what caused the problem the kernel might stop everything (kernel panic because kernel itself crashed), or might send a signal to the thread (e.g. "SIGSEGV") and let the thread/process handle it, or might terminate the process, or might "freeze" all of the process' threads and inform a debugger, or...

Some of the exceptions that always indicate an error are used more for "managed like" languages, where the compiler will put "INTO" and "BOUND" instructions into the code to make sure that common problems (integer overflows, array index out of bounds, etc) are detected if they happen. For some languages (e.g. C, C++) these aren't used (and nothing detects these problems - software is just allowed to crash in weird and wonderful ways that are much harder to debug).

Some of the exceptions that always indicate an error are used for hardware errors, and don't indicate a software problem at all (e.g. machine check exception, and NMI maybe). For these, you can't just terminate the (innocent) process that happened to be running when the hardware failed (and mostly have to treat it more like kernel panic and stop the OS regardless of what was running at the time).

For interrupts in the range 0x20 to 0xFF, these are "free for OS to use". The OS might configure various pieces of hardware (PIC chips, IO APIC, local APIC, PCI devices that use MSI, etc) to use some of these interrupts, and might use some for software interrupts (as part of kernel API), or might not use them. Usually (for more advanced kernels) the kernel will have a kind of "interrupt vector allocator", where a small number of interrupts are used for specific purposes at compile time (e.g. maybe one software interrupt for the kernel API) and the remainder are managed by the "interrupt vector allocator" and dynamically allocated during hardware auto-detection (e.g. during boot the kernel might detect that a certain piece of hardware exists and so it asks the "interrupt vector allocator" to allocate some interrupt vectors for that piece of hardware to use).


Cheers,

Brendan