Function:

Breakpoints are used in the process of debugging programs.
On the 386+, debug registers may be used instead of a one byte opcode.

386 specific debugging bugs occurring on some 386s:
Breakpoints are missed under the following conditions:

- A data breakpoint set to a mem16 operand of a VERR, VERW, LSL or LAR while
  the segment with selector at mem16 is not accessible.

- A data breakpoint is set to the write operand of a REP MOVS instruction
  and the read cycle of the next iteration generates a fault.

- A code or data breakpoint is set on the instruction following a MOV or
  POP to SS while the instruction needs more than two clocks.
  (see <MOV> and <POP>)

Random breakpoints may occur under the following condition:

- Breakpoints set using debug registers DR0 to DR4 may produce spurious
  breaks if breakpoints were enabled before a MOV from CR3, TR6 or TR7 took
  place. These unreliable breaks may continue to occur until the next JMP
  instruction is executed. A workaround would be to:
  = disable breakpoints before any MOV from CR3, TR6 or TR7
  = MOV the values
  = perform a JMP
  = enable breakpoints.

Single stepping is not disabled in the handler for a TSS fault if the code
that caused the fault was being single-stepped and a task gate was used to
handle the fault.

486 specific debugging bugs occurring on some 486s:

A code breakpoint set on control transfer instructions (like CALL, RET, JMP
etc.) will clear the lowest four bits of DR6 when the breakpoint is taken.

A code breakpoint set on an instruction immediately following a RETN, JCXZ,
intrasegment indirect CALL (CALL word ptr [bx] for example) or
intrasegment indirect JMP (JMP word ptr [bx] for example) will always be
satisfied, even when the control instruction is taken. A breakpoint set at
the target of these control transfer instructions will not be taken,
even if control is transferred to them, because the buggy breakpoint sets
the RF (Resume Flag). There is said to be no workaround other than to avoid
the situation, however, coding a nop after the control transfer instruction
and setting the breakpoint to the instruction following the nop may,
according to my view, very well solve the problem. (untested)




BRKEM   Break for emulation (NEC V20/30 only)
──────────────────────────────────────────────────────────────────────────────