INTEL
®
CELERON® PROCESSOR SPECIFICATION UPDATE
26
b)
causes the page table Access or Dirty (A/D) bits to be modified,
the breakpoint information for the MOVSS or POPSS will be lost. Previous Celeron processors retain this
information under these boundary conditions.
Case 3:
If they occur after a MOVSS or POPSS instruction, the INT
n
, INTO, and INT3 instructions zero the
DR6.bi bits (bits B0 through B3), clearing pending breakpoint information, unlike previous In Celeron
processors.
Case 4:
If a data breakpoint and an SMI (System Management Interrupt) occur simultaneously, the SMI will
be serviced via a call to the SMM handler, and the pending breakpoint will be lost.
Case 5:
When an instruction that accesses a debug register is executed, and a breakpoint is encountered on
the instruction, the breakpoint is reported twice.
Case 6:
Unlike previous versions of Intel Architecture processors, Celeron processors will not set the Bi bits
for a matching disabled breakpoint unless at least one other breakpoint is enabled.
Implication:
When debugging or when developing debuggers for a Pentium III processor-based system, this
behavior should be noted. Normal usage of the MOVSS or POPSS instructions (i.e., following them with a
MOV ESP) will not exhibit the behavior of cases 1-3. Debugging in conjunction with SMM will be limited by
case 4.
Workaround:
Following MOVSS and POPSS instructions with a MOV ESP instruction when using
breakpoints will avoid the first three cases of this erratum. No workaround has been identified for cases 4 or 5.
Status:
For the steppings affected see the
Summary of Changes
at the beginning of this section.
C3.
Code Fetch Matching Disabled Debug Register May Cause
Debug Exception
Problem:
The bits L0-3 and G0-3 enable breakpoints local to a task and global to all tasks, respectively. If
one of these bits is set, a breakpoint is enabled, corresponding to the addresses in the debug registers DR0-
DR3. If at least one of these breakpoints is enabled, any of these registers are
disabled
(i.e., L
n
and G
n
are
0), and RW
n
for the disabled register is 00 (indicating a breakpoint on instruction execution), normally an
instruction fetch will not cause an instruction-breakpoint fault based on a match with the address in the
disabled register(s). However, if the address in a disabled register matches the address of a code fetch which
also results in a page fault, an instruction-breakpoint fault will occur.
Implication:
While debugging software, extraneous instruction-breakpoint faults may be encountered if
breakpoint registers are not cleared when they are disabled. Debug software which does not implement a
code breakpoint handler will fail, if this occurs. If a handler is present, the fault will be serviced. Mixing data
and code may exacerbate this problem by allowing disabled data breakpoint registers to break on an
instruction fetch.
Workaround:
The debug handler should clear breakpoint registers before they become disabled.
Status:
For the steppings affected see the
Summary of Changes
at the beginning of this section.
