X86 debug register

Last updated

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.

Contents

DR0 to DR3

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

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.

BitsAbbreviationDescription
0B0Breakpoint #0 Condition Detected [lower-alpha 1]
1B1Breakpoint #1 Condition Detected [lower-alpha 1]
2B2Breakpoint #2 Condition Detected [lower-alpha 1]
3B3Breakpoint #3 Condition Detected [lower-alpha 1]
10:4Reserved.
Read as all-0s on 386/486 processors, all-1s on later processors. [3]
11BLDCleared to 0 by the processor for Bus Lock Trap exceptions. [lower-alpha 2] [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.

12BK,
SMMS
(386/486 only) SMM or ICE mode entered [3] (see also DR7, bit 12).
Reserved and read as 0 on all later processors.
13BDDebug Register Access Detected [lower-alpha 3] [lower-alpha 4] [lower-alpha 5] (see also DR7, bit 13).
14BSSingle-Step execution (enabled by EFLAGS.TF) [lower-alpha 4]
15BTTask Switch breakpoint. [lower-alpha 4]
Occurs when a task switch is done with a TSS that has the T (debug trap flag) bit set.
16RTM(Processors with Intel TSX only)
Cleared to 0 by the processor for debug exceptions inside RTM transactions, [lower-alpha 6] 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:17Reserved.
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. 1 2 3 4 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 using 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. 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. 1 2 3 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 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

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.

BitsAbbreviationDescription
0L0Local enable for breakpoint #0.
1G0Global enable for breakpoint #0.
2L1Local enable for breakpoint #1.
3G1Global enable for breakpoint #1.
4L2Local enable for breakpoint #2.
5G2Global enable for breakpoint #2.
6L3Local enable for breakpoint #3.
7G3Global enable for breakpoint #3.
8LE(386 only) Local Exact Breakpoint Enable. [lower-alpha 1]
9GE(386 only) Global Exact Breakpoint Enable. [lower-alpha 1]
10Reserved, read-only, read as 1 and should be written as 1.
11RTM(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.
12IR,
SMIE
(386/486 processors only) Action on breakpoint match:
0 = INT 1 (#DB exception, default)
1 = Break to ICE/SMM [lower-alpha 2]
On other processors: Reserved, read-only, read as 0 and should be written as 0.
13GDGeneral Detect Enable. If set, will cause a debug exception on any attempt at accessing the DR0-DR7 registers. [lower-alpha 3]
15:14Reserved, should be written as all-0s. [lower-alpha 4]
17:16R/W0Breakpoint condition for breakpoint #0. [lower-alpha 5]
19:18LEN0Breakpoint length for breakpoint #0. [lower-alpha 6]
21:20R/W1Breakpoint condition for breakpoint #1. [lower-alpha 5]
23:22LEN1Breakpoint length for breakpoint #1. [lower-alpha 6]
25:24R/W2Breakpoint condition for breakpoint #2. [lower-alpha 5]
27:26LEN2Breakpoint length for breakpoint #2. [lower-alpha 6]
29:28R/W3Breakpoint condition for breakpoint #3. [lower-alpha 5]
31:30LEN3Breakpoint length for breakpoint #3. [lower-alpha 6]
63:32(x86-64 only) Reserved.
Read as all-0s. Must be written as all-0s.
  1. 1 2 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. 1 2 3 4 The supported breakpoint conditions are:
    ValueBreak on
    00bInstruction execution only
    01bData writes only
    10bI/O reads and writes
    (only defined if CR4.DE=1)
    11bData 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. 1 2 3 4 The supported breakpoint lengths are:
    ValueBreakpoint length
    00b1 byte
    01b2 bytes
    10b8 bytes
    (only defined in 64-bit mode)
    11b4 bytes
    The behavior of using breakpoint length 10b (8 bytes) outside 64-bit mode is undefined.

DR4 and DR5

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

On processor 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. [9]

See also

Related Research Articles

<span class="mw-page-title-main">Interrupt</span> Signal to a computer processor emitted by hardware or software

In digital computers, an interrupt is a request for the processor to interrupt currently executing code, so that the event can be processed in a timely manner. If the request is accepted, the processor will suspend its current activities, save its state, and execute a function called an interrupt handler to deal with the event. This interruption is often temporary, allowing the software to resume normal activities after the interrupt handler finishes, although the interrupt could instead indicate a fatal error.

x86 Family of instruction set architectures

x86 is a family of complex instruction set computer (CISC) instruction set architectures initially developed by Intel based on the Intel 8086 microprocessor and its 8088 variant. The 8086 was introduced in 1978 as a fully 16-bit extension of Intel's 8-bit 8080 microprocessor, with memory segmentation as a solution for addressing more memory than can be covered by a plain 16-bit address. The term "x86" came into being because the names of several successors to Intel's 8086 processor end in "86", including the 80186, 80286, 80386 and 80486 processors. Colloquially, their names were "186", "286", "386" and "486".

x86 memory segmentation refers to the implementation of memory segmentation in the Intel x86 computer instruction set architecture. Segmentation was introduced on the Intel 8086 in 1978 as a way to allow programs to address more than 64 KB (65,536 bytes) of memory. The Intel 80286 introduced a second version of segmentation in 1982 that added support for virtual memory and memory protection. At this point the original mode was renamed to real mode, and the new version was named protected mode. The x86-64 architecture, introduced in 2003, has largely dropped support for segmentation in 64-bit mode.

In computing, protected mode, also called protected virtual address mode, is an operational mode of x86-compatible central processing units (CPUs). It allows system software to use features such as segmentation, virtual memory, paging and safe multi-tasking designed to increase an operating system's control over application software.

x86 assembly language is the name for the family of assembly languages which provide some level of backward compatibility with CPUs back to the Intel 8008 microprocessor, which was launched in April 1972. It is used to produce object code for the x86 class of processors.

INT is an assembly language instruction for x86 processors that generates a software interrupt. It takes the interrupt number formatted as a byte value.

<span class="mw-page-title-main">General protection fault</span>

A general protection fault (GPF) in the x86 instruction set architectures (ISAs) is a fault initiated by ISA-defined protection mechanisms in response to an access violation caused by some running code, either in the kernel or a user program. The mechanism is first described in Intel manuals and datasheets for the Intel 80286 CPU, which was introduced in 1983; it is also described in section 9.8.13 in the Intel 80386 programmer's reference manual from 1986. A general protection fault is implemented as an interrupt. Some operating systems may also classify some exceptions not related to access violations, such as illegal opcode exceptions, as general protection faults, even though they have nothing to do with memory protection. If a CPU detects a protection violation, it stops executing the code and sends a GPF interrupt. In most cases, the operating system removes the failing process from the execution queue, signals the user, and continues executing other processes. If, however, the operating system fails to catch the general protection fault, i.e. another protection violation occurs before the operating system returns from the previous GPF interrupt, the CPU signals a double fault, stopping the operating system. If yet another failure occurs, the CPU is unable to recover; since 80286, the CPU enters a special halt state called "Shutdown", which can only be exited through a hardware reset. The IBM PC AT, the first PC-compatible system to contain an 80286, has hardware that detects the Shutdown state and automatically resets the CPU when it occurs. All descendants of the PC AT do the same, so in a PC, a triple fault causes an immediate system reset.

The x86 instruction set refers to the set of instructions that x86-compatible microprocessors support. The instructions are usually part of an executable program, often stored as a computer file and executed on the processor.

JTAG is an industry standard for verifying designs and testing printed circuit boards after manufacture.

In the 80386 microprocessor and later, virtual 8086 mode allows the execution of real mode applications that are incapable of running directly in protected mode while the processor is running a protected mode operating system. It is a hardware virtualization technique that allowed multiple 8086 processors to be emulated by the 386 chip. It emerged from the painful experiences with the 80286 protected mode, which by itself was not suitable to run concurrent real-mode applications well. John Crawford developed the Virtual Mode bit at the register set, paving the way to this environment.

<span class="mw-page-title-main">Breakpoint</span> Debugging method used in software development

In software development, a breakpoint is an intentional stopping or pausing place in a program, put in place for debugging purposes. It is also sometimes simply referred to as a pause.

The Pentium F00F bug is a design flaw in the majority of Intel Pentium, Pentium MMX, and Pentium OverDrive processors. Discovered in 1997, it can result in the processor ceasing to function until the computer is physically rebooted. The bug has been circumvented through operating system updates.

Jazelle DBX is an extension that allows some ARM processors to execute Java bytecode in hardware as a third execution state alongside the existing ARM and Thumb modes. Jazelle functionality was specified in the ARMv5TEJ architecture and the first processor with Jazelle technology was the ARM926EJ-S. Jazelle is denoted by a "J" appended to the CPU name, except for post-v5 cores where it is required for architecture conformance.

A Trace Vector Decoder (TVD) is computer software that uses the trace facility of its underlying microprocessor to decode encrypted instruction opcodes just-in-time prior to execution and possibly re-encode them afterwards. It can be used to hinder reverse engineering when attempting to prevent software cracking as part of an overall copy protection strategy.

A control register is a processor register that changes or controls the general behavior of a CPU or other digital device. Common tasks performed by control registers include interrupt control, switching the addressing mode, paging control, and coprocessor control.

A test register, in the Intel 80386 and Intel 80486 processor, was a register used by the processor, usually to do a self-test. Most of these registers were undocumented, and used by specialized software. The test registers were named TR3 to TR7. Regular programs don't usually require these registers to work. With the Pentium, the test registers were replaced by a variety of model-specific registers (MSRs).

The 65xx family of microprocessors, consisting of the MOS Technology 6502 and its derivatives, the WDC 65C02, WDC 65C802 and WDC 65C816, and CSG 65CE02, all handle interrupts in a similar fashion. There are three hardware interrupt signals common to all 65xx processors and one software interrupt, the BRK instruction. The WDC 65C816 adds a fourth hardware interrupt—ABORT, useful for implementing virtual memory architectures—and the COP software interrupt instruction, intended for use in a system with a coprocessor of some type.

A model-specific register (MSR) is any of various control registers in the x86 system architecture used for debugging, program execution tracing, computer performance monitoring, and toggling certain CPU features.

Intel microcode is microcode that runs inside x86 processors made by Intel. Since the P6 microarchitecture introduced in the mid-1990s, the microcode programs can be patched by the operating system or BIOS firmware to work around bugs found in the CPU after release. Intel had originally designed microcode updates for processor debugging under its design for testing (DFT) initiative.

References

  1. 1 2 3 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. 1 2 3 4 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. Geoff Chappell, CPU Identification Before CPUID, 30 dec 2021. Accessed on 29 jan 2023.