Volume 3B System Programming Guide_ Part 2 (794104), страница 3
Текст из файла (страница 3)
The processor generates a debug exception for any of several conditions. The debugger checks flags in the DR6 and DR7 registers to determine whichcondition caused the exception and which other conditions might apply. Table 18-2shows the states of these flags following the generation of each kind of breakpointcondition.Instruction-breakpoint and general-detect condition (see Section 18.3.1.3, “GeneralDetect Exception Condition”) result in faults; other debug-exception conditions resultin traps. The debug exception may report one or both at one time. The followingsections describe each class of debug exception.See also: Chapter 5, “Interrupt 1—Debug Exception (#DB),” in the Intel® 64 andIA-32 Architectures Software Developer’s Manual, Volume 3A.Table 18-2. Debug Exception ConditionsDebug or Breakpoint ConditionDR6 FlagsTestedSingle-step trapBS = 1Instruction breakpoint, at addressesdefined by DRn and LENnBn = 1 and(Gn or Ln = 1)R/Wn = 0FaultData write breakpoint, at addressesdefined by DRn and LENnBn = 1 and(Gn or Ln = 1)R/Wn = 1TrapI/O read or write breakpoint, ataddresses defined by DRn and LENnBn = 1 and(Gn or Ln = 1)R/Wn = 2TrapData read or write (but not instructionfetches), at addresses defined by DRnand LENnBn = 1 and(Gn or Ln = 1)R/Wn = 3TrapGeneral detect fault, resulting from anattempt to modify debug registers(usually in conjunction with in-circuitemulation)BD = 1FaultTask switchBT = 1Trap18.3.1.1DR7 FlagsTestedException ClassTrapInstruction-Breakpoint Exception ConditionThe processor reports an instruction breakpoint when it attempts to execute aninstruction at an address specified in a breakpoint-address register (DB0 throughDR3) that has been set up to detect instruction execution (R/W flag is set to 0).
UponVol. 3 18-9DEBUGGING AND PERFORMANCE MONITORINGreporting the instruction breakpoint, the processor generates a fault-class, debugexception (#DB) before it executes the target instruction for the breakpoint.Instruction breakpoints are the highest priority debug exceptions. They are servicedbefore any other exceptions detected during the decoding or execution of an instruction. However, if a code instruction breakpoint is placed on an instruction locatedimmediately after a POP SS/MOV SS instruction, the breakpoint may not be triggered.
In most situations, POP SS/MOV SS will inhibit such interrupts (see“MOV—Move” and “POP—Pop a Value from the Stack” in Chapters 3 and 4 of theIntel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes2A & 2B).Because the debug exception for an instruction breakpoint is generated before theinstruction is executed, if the instruction breakpoint is not removed by the exceptionhandler; the processor will detect the instruction breakpoint again when the instruction is restarted and generate another debug exception. To prevent looping on aninstruction breakpoint, the Intel 64 and IA-32 architectures provide the RF flag(resume flag) in the EFLAGS register (see Section 2.3, “System Flags and Fields inthe EFLAGS Register,” in the Intel® 64 and IA-32 Architectures Software Developer’sManual, Volume 3A). When the RF flag is set, the processor ignores instructionbreakpoints.All Intel 64 and IA-32 processors manage the RF flag as follows.
The RF Flag iscleared at the start of the instruction after the check for code breakpoint, CS limitviolation and FP exceptions. Task Switches and IRETD/IRETQ instructions transferthe RF image from the TSS/stack to the EFLAGS register.When calling an event handler, Intel 64 and IA-32 processors establish the value ofthe RF flag in the EFLAGS image pushed on the stack:•For any fault-class exception except a debug exception generated in response toan instruction breakpoint, the value pushed for RF is 1.•For any interrupt arriving after any iteration of a repeated string instruction butthe last iteration, the value pushed for RF is 1.•For any trap-class exception generated by any iteration of a repeated stringinstruction but the last iteration, the value pushed for RF is 1.•For other cases, the value pushed for RF is the value that was in EFLAG.RF at thetime the event handler was called.
This includes:— Debug exceptions generated in response to instruction breakpoints— Hardware-generated interrupts arriving between instructions (includingthose arriving after the last iteration of a repeated string instruction)— Trap-class exceptions generated after an instruction completes (includingthose generated after the last iteration of a repeated string instruction)— Software-generated interrupts (RF is pushed as 0, since it was cleared at thestart of the software interrupt)18-10 Vol. 3DEBUGGING AND PERFORMANCE MONITORINGAs noted above, the processor does not set the RF flag prior to calling the debugexception handler for debug exceptions resulting from instruction breakpoints.
Thedebug exception handler can prevent recurrence of the instruction breakpoint bysetting the RF flag in the EFLAGS image on the stack. If the RF flag in the EFLAGSimage is set when the processor returns from the exception handler, it is copied intothe RF flag in the EFLAGS register by IRETD/IRETQ or a task switch that causes thereturn. The processor then ignores instruction breakpoints for the duration of thenext instruction. (Note that the POPF, POPFD, and IRET instructions do not transferthe RF image into the EFLAGS register.) Setting the RF flag does not prevent othertypes of debug-exception conditions (such as, I/O or data breakpoints) from beingdetected, nor does it prevent non-debug exceptions from being generated.For the Pentium processor, when an instruction breakpoint coincides with anotherfault-type exception (such as a page fault), the processor may generate one spuriousdebug exception after the second exception has been handled, even though thedebug exception handler set the RF flag in the EFLAGS image.
To prevent a spuriousexception with Pentium processors, all fault-class exception handlers should set theRF flag in the EFLAGS image.18.3.1.2Data Memory and I/O Breakpoint Exception ConditionsData memory and I/O breakpoints are reported when the processor attempts toaccess a memory or I/O address specified in a breakpoint-address register (DB0through DR3) that has been set up to detect data or I/O accesses (R/W flag is set to1, 2, or 3). The processor generates the exception after it executes the instructionthat made the access, so these breakpoint condition causes a trap-class exception tobe generated.Because data breakpoints are traps, the original data is overwritten before the trapexception is generated.
If a debugger needs to save the contents of a write breakpoint location, it should save the original contents before setting the breakpoint. Thehandler can report the saved value after the breakpoint is triggered. The address inthe debug registers can be used to locate the new value stored by the instruction thattriggered the breakpoint.Intel486 and later processors ignore the GE and LE flags in DR7. In Intel386 processors, exact data breakpoint matching does not occur unless it is enabled by settingthe LE and/or the GE flags.P6 family processors are unable to report data breakpoints exactly for the REP MOVSand REP STOS instructions until the completion of the iteration after the iteration inwhich the breakpoint occurred.For repeated INS and OUTS instructions that generate an I/O-breakpoint debugexception, the processor generates the exception after the completion of the firstiteration.
Repeated INS and OUTS instructions generate an I/O-breakpoint debugexception after the iteration in which the memory address breakpoint location isaccessed.Vol. 3 18-11DEBUGGING AND PERFORMANCE MONITORING18.3.1.3General-Detect Exception ConditionWhen the GD flag in DR7 is set, the general-detect debug exception occurs when aprogram attempts to access any of the debug registers (DR0 through DR7) at thesame time they are being used by another application, such as an emulator ordebugger. This protection feature guarantees full control over the debug registerswhen required. The debug exception handler can detect this condition by checkingthe state of the BD flag in the DR6 register.
The processor generates the exceptionbefore it executes the MOV instruction that accesses a debug register, which causesa fault-class exception to be generated.18.3.1.4Single-Step Exception ConditionThe processor generates a single-step debug exception if (while an instruction isbeing executed) it detects that the TF flag in the EFLAGS register is set.
The exception is a trap-class exception, because the exception is generated after the instruction is executed. The processor will not generate this exception after the instructionthat sets the TF flag. For example, if the POPF instruction is used to set the TF flag, asingle-step trap does not occur until after the instruction that follows the POPFinstruction.The processor clears the TF flag before calling the exception handler.
If the TF flagwas set in a TSS at the time of a task switch, the exception occurs after the firstinstruction is executed in the new task.The TF flag normally is not cleared by privilege changes inside a task. The INT n andINTO instructions, however, do clear this flag. Therefore, software debuggers thatsingle-step code must recognize and emulate INT n or INTO instructions rather thanexecuting them directly. To maintain protection, the operating system should checkthe CPL after any single-step trap to see if single stepping should continue at thecurrent privilege level.The interrupt priorities guarantee that, if an external interrupt occurs, single stepping stops. When both an external interrupt and a single-step interrupt occurtogether, the single-step interrupt is processed first. This operation clears the TF flag.After saving the return address or switching tasks, the external interrupt input isexamined before the first instruction of the single-step handler executes.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
