| blob | 0c96612554448c8a51da77868e34b1cd851606f9 |
2 <HTML>
3 <HEAD>
5 </HEAD>
6 <BODY>
12 <P>
13 <HR>
14 <P>
16 Two of the interrupt vectors of the 80386 are reserved for exceptions that
17 relate to debugging. Interrupt 1 is the primary means of invoking debuggers
19 debuggers and for compatibility with prior processors in Intel's 8086
20 processor family.
23 The handler for this exception is usually a debugger or part of a debugging
24 system. The processor causes interrupt 1 for any of several conditions. The
25 debugger can check flags in DR6 and DR7 to determine what condition caused
26 the exception and what other conditions might be in effect at the same time.
28 associates with each breakpoint condition the combination of
29 bits that indicate when that condition has caused the debug exception.
30 <P>
31 Instruction address breakpoint conditions are faults, while other debug
32 conditions are traps. The debug exception may report either or both at one
33 time. The following paragraphs present details for each class of debug
34 exception.
36 <PRE>
39 Flags to Test Condition
41 BS=1 Single-step trap
47 BT=1 Task switch
49 </PRE>
50 </A>
52 The processor reports an instruction-address breakpoint before it executes
53 the instruction that begins at the given address; i.e., an instruction-
54 address breakpoint exception is a fault.
55 <P>
56 The RF (restart flag) permits the debug handler to retry instructions that
57 cause other kinds of faults in addition to debug faults. When it detects a
58 fault, the processor automatically sets RF in the flags image that it pushes
59 onto the stack. (It does not, however, set RF for traps and aborts.)
60 <P>
61 When RF is set, it causes any debug fault to be ignored during the next
62 instruction. (Note, however, that RF does not cause breakpoint traps to be
63 ignored, nor other kinds of faults.)
64 <P>
65 The processor automatically clears RF at the successful completion of every
66 instruction except after the
69 and after a
73 instructions set RF to the value specified by the memory image of the EFLAGS
74 register.
75 <P>
76 The processor automatically sets RF in the EFLAGS image on the stack before
77 entry into any fault handler. Upon entry into the fault handler for
78 instruction address breakpoints, for example, RF is set in the EFLAGS image
79 on the stack; therefore, the
81 set RF in the EFLAGS register, and execution will resume at the breakpoint
82 address without generating another breakpoint fault at the same address.
83 <P>
84 If, after a debug fault, RF is set and the debug handler retries the
85 faulting instruction, it is possible that retrying the instruction will
86 raise other faults. The retry of the instruction after these faults will
87 also be done with RF=1, with the result that debug faults continue to be
88 ignored. The processor clears RF only after successful completion of the
89 instruction.
90 <P>
91 Real-mode debuggers can control the RF flag by using a 32-bit
93 16-bit
95 (which is in the
97 rearrange the stack so that it holds appropriate values for the 32-bit EIP,
98 CS, and EFLAGS (with RF set in the EFLAGS image). Then executing an
100 with an operand size prefix causes a 32-bit return, popping the RF flag
101 into EFLAGS.
104 A data-address breakpoint exception is a trap; i.e., the processor reports
105 a data-address breakpoint after executing the instruction that accesses the
106 given memory item.
107 <P>
108 When using data breakpoints it is recommended that either the LE or GE bit
109 of DR7 be set also. If either LE or GE is set, any data breakpoint trap is
110 reported exactly after completion of the instruction that accessed the
111 specified memory item. This exact reporting is accomplished by forcing the
112 80386 execution unit to wait for completion of data operand transfers before
113 beginning execution of the next instruction. If neither GE nor LE is set,
114 data breakpoints may not be reported until one instruction after the data is
115 accessed or may not be reported at all. This is due to the fact that,
116 normally, instruction execution is overlapped with memory transfers to such
117 a degree that execution of the next instruction may begin before memory
118 transfers for the prior instruction are completed.
119 <P>
120 If a debugger needs to preserve the contents of a write breakpoint
121 location, it should save the original contents before setting a write
122 breakpoint. Because data breakpoints are traps, a write into a breakpoint
123 location will complete before the trap condition is reported. The handler
124 can report the saved value after the breakpoint is triggered. The data in
125 the debug registers can be used to address the new value stored by the
126 instruction that triggered the breakpoint.
129 This exception occurs when an attempt is made to use the debug registers at
130 the same time that ICE-386 is using them. This additional protection feature
131 is provided to guarantee that ICE-386 can have full control over the
132 debug-register resources when required. ICE-386 uses the debug-registers;
133 therefore, a software debugger that also uses these registers cannot run
134 while ICE-386 is in use. The exception handler can detect this condition by
135 examining the BD bit of DR6.
138 This debug condition occurs at the end of an instruction if the trap flag
139 (TF) of the flags register held the value one at the beginning of that
140 instruction. Note that the exception does not occur at the end of an
141 instruction that sets TF. For example, if
143 single-step trap does not occur until after the instruction that follows
145 <P>
146 The processor clears the TF bit before invoking the handler. If TF=1 in
147 the flags image of a TSS at the time of a task switch, the exception occurs
148 after the first instruction is executed in the new task.
149 <P>
150 The single-step flag is normally not cleared by privilege changes inside a
151 task.
153 Therefore, software
154 debuggers that single-step code must recognize and emulate
157 rather than executing them directly.
158 <P>
159 To maintain protection, system software should check the current execution
160 privilege level after any single step interrupt to see whether single
161 stepping should continue at the current privilege level.
162 <P>
163 The interrupt priorities in hardware guarantee that if an external
164 interrupt occurs, single stepping stops. When both an external interrupt and
165 a single step interrupt occur together, the single step interrupt is
166 processed first. This clears the TF bit. After saving the return address or
167 switching tasks, the external interrupt input is examined before the first
168 instruction of the single step handler executes. If the external interrupt
169 is still pending, it is then serviced. The external interrupt handler is not
170 single-stepped. To single step an interrupt handler, just single step an
172 n instruction that refers to the interrupt handler.
175 The debug exception also occurs after a switch to an 80386 task if the
176 T-bit of the new TSS is set. The exception occurs after control has passed
177 to the new task, but before the first instruction of that task is executed.
178 The exception handler can detect this condition by examining the
179 BT bit of
180 the debug status register DR6.
181 <P>
182 Note that if the debug exception handler is a task, the T-bit of its TSS
183 should not be set. Failure to observe this rule will cause the processor to
184 enter an infinite loop.
187 This exception is caused by execution of the breakpoint instruction
189 Typically, a debugger prepares a breakpoint by substituting the opcode of
190 the one-byte breakpoint instruction in place of the first opcode byte of the
191 instruction to be trapped. When execution of the
193 the exception handler to be invoked, the saved value of ES:EIP points to the
195 <P>
196 With prior generations of processors, this feature is used extensively for
197 trapping execution of specific instructions. With the 80386, the needs
198 formerly filled by this feature are more conveniently solved via the debug
199 registers and interrupt 1. However, the breakpoint exception is still
200 useful for debugging debuggers, because the breakpoint exception can vector
201 to a different exception handler than that used by the debugger. The
202 breakpoint exception can also be useful when it is necessary to set a
203 greater number of breakpoints than permitted by the debug registers.
204 <P>
205 <HR>
206 <P>
212 </BODY>