Jump to content

x86 debug register

From Wikipedia, the free encyclopedia
(Redirected from Debug register)

On the x86 architecture, a debug register is a register used by a processor for program debugging. There are six debug registers, named DR0...DR7, with DR4 and DR5 as obsolete synonyms for DR6 and DR7. The debug registers allow programmers to selectively enable various debug conditions associated with a set of four debug addresses. Two of these registers are used to control debug features. These registers are accessed by variants of the MOV instruction. A debug register may be either the source operand or destination operand. The debug registers are privileged resources; the MOV instructions that access them can only be executed at privilege level zero. An attempt to read or write the debug registers when executing at any other privilege level causes a general protection fault.

DR0 to DR3

[edit]

Each of these registers contains the linear address associated with one of four breakpoint conditions. Each breakpoint condition is further defined by bits in DR7.

The debug address registers are effective whether or not paging is enabled. The addresses in these registers are linear addresses. If paging is enabled, the linear addresses are translated into physical addresses by the processor's paging mechanism. If paging is not enabled, these linear addresses are the same as physical addresses.

Note that when paging is enabled, different tasks may have different linear-to-physical address mappings. When this is the case, an address in a debug address register may be relevant to one task but not to another. For this reason the x86 has both global and local enable bits in DR7. These bits indicate whether a given debug address has a global (all tasks) or local (current task only) relevance.

DR6 - Debug status

[edit]

The debug status register permits the debugger to determine which debug conditions have occurred. When the processor detects an enabled debug exception, it will set the corresponding bits of this register before entering the debug exception handler.

Bits Abbreviation Description
0 B0 Breakpoint #0 Condition Detected[a]
1 B1 Breakpoint #1 Condition Detected[a]
2 B2 Breakpoint #2 Condition Detected[a]
3 B3 Breakpoint #3 Condition Detected[a]
10:4 Reserved.
Read as all-0s on 386/486 processors, all-1s on later processors.[3]
11 BLD Cleared to 0 by the processor for Bus Lock Trap exceptions.[b][4]

On processors that don't support Bus Lock Trap exceptions, bit 11 of DR6 is a read-only bit, acting in the same way as bits 10:4.

12 BK,
SMMS
(386/486 only) SMM or ICE mode entered[3] (see also DR7, bit 12).
Reserved and read as 0 on all later processors.
13 BD Debug Register Access Detected[c][d][e] (see also DR7, bit 13).
14 BS Single-Step execution (enabled by EFLAGS.TF)[d]
15 BT Task Switch breakpoint.[d]
Occurs when a task switch is done with a TSS that has the T (debug trap flag) bit set.
16 RTM (Processors with Intel TSX only)
Cleared to 0 by the processor for debug exceptions inside RTM transactions,[f] set to 1 for all debug exceptions outside transactions.
On processors without TSX, bit 16 of DR6 is a read-only bit, acting in the same way as bits 31:17.
31:17 Reserved.
Read as all-0s on 386/486/6x86 processors, all-1s on later processors.
63:32 (x86-64 only) Reserved.
Read as all-0s. Must be written as all-0s.
  1. ^ a b c d B0-B3 are set for each breakpoint condition that was met at the time that a debug exception was generated.

    In some implementations, B0-B3 can be set for breakpoints that match but are not enabled[1] - therefore, the debug handler should only check bits that correspond to enabled breakpoints.

    Also, it is implementation-dependent whether hardware will clear B0-B3 for non-matching breakpoint conditions - therefore, debug handlers are recommended to manually clear these bits before returning to the interrupted task.[2]

  2. ^ When Bus Lock Trap is enabled using bit 2 of DEBUGCTL (MSR 1D9h), any instruction that causes a Bus Lock (mainly instructions that use the LOCK prefix to perform memory atomics that straddle cache-line boundaries or operate on uncacheable memory) will clear bit 11 of DR6 and cause a trap-type #DB exception. This bit is not otherwise set or cleared by the processors - debug handlers are recommended to set this bit to 1 before returning to the interrupted task.
  3. ^ The BD bit indicates that the next instruction in the instruction stream is one that accesses a debug register.

    In some implementations, this bit may be set even if DR7.GD is not set.[1]

  4. ^ a b c Bits 13,14 and 15 of DR6 are never cleared by hardware - therefore, debug handlers are recommended to manually clear these bits before returning to the interrupted task.
  5. ^ Bit 13 of DR6 is reserved on all Cyrix processors.
  6. ^ If a debug exception condition is detected inside a transaction, then the processor will abort the transaction. If advanced debugging of RTM transactions is enabled, it will then raise the debug exception as a fault-type exception on the XBEGIN instruction that started the transaction, otherwise the transaction is aborted with no exceptions raised.

DR7 - Debug control

[edit]

The debug control register is used to selectively enable the four address breakpoint conditions, and to specify the type and size of each of the four breakpoints. There are two levels of enabling: the local (0,2,4,6) and global (1,3,5,7) levels. The local enable bits are automatically reset by the processor at every task switch to avoid unwanted breakpoint conditions in the new task. The global enable bits are not reset by a task switch; therefore, they can be used for conditions that are global to all tasks.

Bits Abbreviation Description
0 L0 Local enable for breakpoint #0.
1 G0 Global enable for breakpoint #0.
2 L1 Local enable for breakpoint #1.
3 G1 Global enable for breakpoint #1.
4 L2 Local enable for breakpoint #2.
5 G2 Global enable for breakpoint #2.
6 L3 Local enable for breakpoint #3.
7 G3 Global enable for breakpoint #3.
8 LE (386 only) Local Exact Breakpoint Enable.[a]
9 GE (386 only) Global Exact Breakpoint Enable.[a]
10 Reserved, read-only, read as 1 and should be written as 1.
11 RTM (Processors with Intel TSX only)
Enable advanced debugging of RTM transactions (only if DEBUGCTL bit 15 is also set)
On other processors: reserved, read-only, read as 0 and should be written as 0.
12 IR,
SMIE
(386/486 processors only) Action on breakpoint match:
0 = INT 1 (#DB exception, default)
1 = Break to ICE/SMM[b]
On other processors: Reserved, read-only, read as 0 and should be written as 0.
13 GD General Detect Enable. If set, will cause a debug exception on any attempt at accessing the DR0-DR7 registers.[c]
15:14 Reserved, should be written as all-0s.[d]
17:16 R/W0 Breakpoint condition for breakpoint #0.[e]
19:18 LEN0 Breakpoint length for breakpoint #0.[f]
21:20 R/W1 Breakpoint condition for breakpoint #1.[e]
23:22 LEN1 Breakpoint length for breakpoint #1.[f]
25:24 R/W2 Breakpoint condition for breakpoint #2.[e]
27:26 LEN2 Breakpoint length for breakpoint #2.[f]
29:28 R/W3 Breakpoint condition for breakpoint #3.[e]
31:30 LEN3 Breakpoint length for breakpoint #3.[f]
32 DR0_PT_LOG Enable DR0/1/2/3 breakpoint match as a trigger input for PTTT (Processor Trace Trigger Tracing).[9]

Read as 0 and must be written as all-0s on processors that don't support PTTT.[g]

33 DR1_PT_LOG
34 DR2_PT_LOG
35 DR3_PT_LOG
63:36 (x86-64 only) Reserved.
Read as all-0s. Must be written as all-0s.
  1. ^ a b On 80386 processors, enabling exact breakpoints causes data breakpoint exceptions to be raised as trap-type exceptions for the instruction that performed the data access. If exact breakpoints are not enabled, then data breakpoint exceptions may be delayed by one or more instructions.[5] Enabling exact breakpoints comes at a significant performance cost on the 80386.[1]

    On later processors, breakpoints are always exact - bits 9:8 of DR7 are still present as writable bits and are recommended to be set, but are ignored by the CPU.

  2. ^ Setting bit 12 of DR7 to 1 modifies the action of breakpoints, single-stepping, general-detect (see bit 13), and behavior of the F1h ("ICEBP"/"INT01") opcode to:
  3. ^ Before entry to the debug exception handler, bit 13 of DR6 will be set and bit 13 of DR7 will be cleared so that the DR0-DR7 registers can be accessed within the handler.
  4. ^ On some 386/486 processors, bit 14 of DR7 is reported to enable branch trace messages[8] and bit 15 to enable task trace messages.[3] These messages are intended for use with In-circuit emulation and may cause system instability if an ICE is not connected.
  5. ^ a b c d The supported breakpoint conditions are:
    Value Break on
    00b Instruction execution only
    01b Data writes only
    10b I/O reads and writes
    (only defined if CR4.DE=1)
    11b Data reads and writes
    The behavior of using breakpoint type 10b on processors where the CR4.DE bit is missing or set to zero is undefined.

    For instruction execution breakpoints, the breakpoint length must be set to 00b (1 byte) or else behavior is undefined.

  6. ^ a b c d The supported breakpoint lengths are:
    Value Breakpoint length
    00b 1 byte
    01b 2 bytes
    10b 8 bytes
    (only defined in 64-bit mode)
    11b 4 bytes
    For breakpoint lengths greater than 1 byte, the address of the given breakpoint is rounded down to the nearest multiple of the breakpoint length.

    The behavior of using breakpoint length 10b (8 bytes) outside 64-bit mode is undefined.

  7. ^ On processors that support PTTT, writing to DR7 while not in 64-bit mode will leave bits 35:32 of DR7 unmodified.

DR4 and DR5

[edit]

Not real registers. On processors that support the CR4.DE bit (Intel Pentium and later), their behaviour is controlled by CR4.DE:

  • CR4.DE=0 : DR4 and DR5 alias to DR6 and DR7, respectively.
  • CR4.DE=1 : accessing DR4/5 results in #UD (invalid opcode) exception.

On processors without CR4.DE, the behaviour is officially undefined - usually, DR4/5 are aliased to DR6/7, but exceptions exist and have been used for CPU detection.[10]

See also

[edit]

References

[edit]
  1. ^ a b c John Crawford and Pat Gelsinger, "Programming the 80386", 1987 (ISBN 0-89588-381-3), chapter 8, pages 635-636
  2. ^ Intel, Software Developer's Manual, order no. 325462-078, dec 2022, volume 3, section, 18.2.3, page 3640
  3. ^ a b c d Potemkin's Hackers Group, OPCODE.LST rev 4.51, 15 oct 1999
  4. ^ Intel, Intel® 64 and IA-32 Architectures Software Developer’s Manual, order no. 325462-079, March 2023, Volume 3, chapter 18.2.3 and 18.3.1.6 on pages 3636 and 3643
  5. ^ AMD, Am386 Microprocessors for Personal Computers Data Book, order no. 11339C, 15 oct 1992, page 38.
  6. ^ Robert Collins, Intel's System Management Mode, Jan 1997. Archived from the original on Jun 13, 1997.
  7. ^ "Am386®SX/SXL/SXLV High-Performance, Low-Power, Embedded Microprocessors" (PDF)., publication #21020, rev A, apr 1997, pages 5 and 6.
  8. ^ Robert Collins, Undocumented bits in DR7. Archived from the original on Dec 01, 1996
  9. ^ Intel, Intel Architecture Instruction Set Extensions and Future Features, order no. 314933-053, Jun 2024, section 16.2.3, page 216. Archived on 28 Jul 2024.
  10. ^ Geoff Chappell, CPU Identification Before CPUID, 4 Mar 2023. Accessed on 6 Sep 2024. Archived on 3 Jun 2024.
  • Intel 80386 Programmer's Reference
[edit]