The Intel manual tells me Exception vector 1 is reserved (its mnemonic: #DB)
See Chapter 5.3 : Table 5-1 for this.
In most source codes I of other people's OS I see they just map this interrupt to an exception handler that prints "Debug Fault" to the screen.
While the Intel manual says its reserved. Is it really reserved?
Debug Fault Exception
Well, my old manuals (from years 1993, 1997 and 1988) are saying that INT 0x01 is a debug exception. It triggers when the TF flag in EFLAGS is set to 1. It triggers in my OS when you enter Bochs debugger (CTRL+C) and when you gain back control to my OS. Voila, RSOD with INT 0x01 "exception"... which should be immediately fixed
And, Hardware Breakpoints, "advanced-debugging method" available from 80386 (never used them) are a "extension" to INT 0x01. They can guard CPU opcodes and verify memory reading and writing, if I translated this correctly.
It sounds weird, but I'm not supporting debugging in my OS, at least not in the upcoming release.![Smile :)](./images/smilies/icon_smile.gif)
inflater
![Laughing :lol:](./images/smilies/icon_lol.gif)
It sounds weird, but I'm not supporting debugging in my OS, at least not in the upcoming release.
![Smile :)](./images/smilies/icon_smile.gif)
inflater
My web site: http://inflater.wz.cz (Slovak)
Derrick operating system: http://derrick.xf.cz (Slovak and English
)
Derrick operating system: http://derrick.xf.cz (Slovak and English
![Razz :P](./images/smilies/icon_razz.gif)
Why then hang on that interrupt if it causes your entire OS to hang when debugging in Bochs ![Razz :P](./images/smilies/icon_razz.gif)
Well, in another paragraph of the same chapter they say this:
[quote]5.8.2Masking Instruction Breakpoints
............
When set, it prevents an instruction breakpoint from generating a debug exception (#DB); when
clear, instruction breakpoints will generate debug exceptions. The primary function of the RF
flag is to prevent the processor from going into a debug exception loop on an instruction-break-
point. See Section 18.3.1.1, “Instruction-Breakpoint Exception Condition,â€
![Razz :P](./images/smilies/icon_razz.gif)
Well, in another paragraph of the same chapter they say this:
[quote]5.8.2Masking Instruction Breakpoints
............
When set, it prevents an instruction breakpoint from generating a debug exception (#DB); when
clear, instruction breakpoints will generate debug exceptions. The primary function of the RF
flag is to prevent the processor from going into a debug exception loop on an instruction-break-
point. See Section 18.3.1.1, “Instruction-Breakpoint Exception Condition,â€
INT 0x01 were Debug Exception handler. Now, when it is reserved,... well, maybe Intel will use it for system overclocking or enhancing 3D performance in games, in the future ![Laughing :lol:](./images/smilies/icon_lol.gif)
j/k![Smile :)](./images/smilies/icon_smile.gif)
inflater
![Laughing :lol:](./images/smilies/icon_lol.gif)
j/k
![Smile :)](./images/smilies/icon_smile.gif)
inflater
My web site: http://inflater.wz.cz (Slovak)
Derrick operating system: http://derrick.xf.cz (Slovak and English
)
Derrick operating system: http://derrick.xf.cz (Slovak and English
![Razz :P](./images/smilies/icon_razz.gif)
Haha I like your humorinflater wrote:INT 0x01 were Debug Exception handler. Now, when it is reserved,... well, maybe Intel will use it for system overclocking or enhancing 3D performance in games, in the future
j/k
inflater
![Laughing :lol:](./images/smilies/icon_lol.gif)
Well it's weird that they actually change things later on (if its not just errata) while they have many reserved interrupts later on in the IDT. Besides, they really strive towards backwards-compatibility, so this is a little odd if its true.