参照文档x86 cpu《Intel® 6 4 and IA-32 Architectures Software Developer’s Manual》和arm cpu 《Arm®Architecture Reference Manual》，都支持hardware breakpoint。
对于x86 cpu如下(来自《Intel® 6 4 and IA-32 Architectures Software Developer’s Manual》)：
保护模式下的异常中断vector分类，其中vector 1是debug exception，其中包括data类型的读写。
Table 6-1. Protected-Mode Exceptions and Interrupts
|
Vector
|
Mnemonic
|
Description
|
Type
|
Error Code
|
Source
|
| 0 |
#DE
|
Divide Error
|
Fault
|
No |
DIV and IDIV instructions.
|
| 1 |
#DB
|
Debug Exception
|
Fault/ Trap
|
No |
Instruction, data, and I/O breakpoints;
single-step; and others.
|
Data read or write breakpoint是一种trap类型的异常，定位内存被踩就可以使用它。
Interrupt 1—Debug Exception (#DB)
Exception Class
Trap or Fault. The exception handler can distinguish between traps or faults by exam
ining the contents of DR6 and the other debug registers.
Description
Indicates that one or more of several debug-exception conditions has been detected. Whether the exception is a
fault or a trap depends on the condition (see Table 6-3). See Chapter 18, “Debug, Branch Profile, TSC, and Intel®
Resource Director Technology (Intel® RDT) Features,” for detailed information about the debug exceptions.
Table 6-3. Debug Exception Conditions and Corresponding Exception Classes
|
Exception Condition
|
Exception Class
|
|
Instruction fetch breakpoint
|
Fault
|
|
Data read or write breakpoint
|
Trap
|
|
I/O read or write breakpoint
|
Trap
|
|
General detect condition (in conjunction with in-circuit emulation)
|
Fault
|
|
Single-step
|
Trap
|
|
Task-switch
|
Trap
|
|
Execution of INT1
|
Trap
|
x86 CPU通过8个寄存器来实现hardware breakpoint：
DR0-DR7
Debug registers are privileged resources; a MOV instruction that accesses these registers can only be executed in
real-address mode, in SMM or in protected mode at a CPL of 0. An attempt to read or write the debug registers
from any other privilege level generates a general-protection exception (#GP).
The primary function of the debug registers is to set up and monitor from 1 to 4 breakpoints, numbered 0 though
3. For each breakpoint, the following information can be specified:
• The linear address where the breakpoint is to occur.
• The length of the breakpoint location: 1, 2, 4, or 8 bytes (refer to the notes in Section 18.2.4).
• The operation that must be performed at the address for a debug exception to be generated.
• Whether the breakpoint is enabled.
• Whether the breakpoint condition was present when the debug exception was generated.
The following paragraphs describe the functions of flags and fields in the debug registers.
18.2.1 Debug Address Registers (DR0-DR3)
Each of the debug-address registers (DR0 through DR3) holds the 32-bit linear address of a breakpoint (see
Figure 18-1). Breakpoint comparisons are made before physical address translation occurs. The contents of debug
register DR7 further specifies breakpoint conditions.
18.2.2 Debug Registers DR4 and DR5
Debug registers DR4 and DR5 are reserved when debug extensions are enabled (when the DE flag in control
register CR4 is set) and attempts to reference the DR4 and DR5 registers cause invalid-opcode exceptions (#UD).
When debug extensions are not enabled (when the DE flag is clear), these registers are aliased to debug registers
DR6 and DR7.
18.2.3 Debug Status Register (DR6)
The debug status register (DR6) reports debug conditions that were sampled at the time the last debug exception
was generated (see Figure 18-1). Updates to this register only occur when an exception is generated. The flags in
this register show the following information:
• B0 through B3 (breakpoint condition detected) flags (bits 0 through 3) — Indicates (when set) that its
associated breakpoint condition was met when a debug exception was generated. These flags are set if the
condition described for each breakpoint by the LENn, and R/Wn flags in debug control register DR7 is true. They
may or may not be set if the breakpoint is not enabled by the Ln or the Gn flags in register DR7. Therefore on
a #DB, a debug handler should check only those B0-B3 bits which correspond to an enabled breakpoint.
• BLD (bus-lock detected) flag (bit 11) — Indicates (when clear) that the debug exception was triggered by
the assertion of a bus lock when CPL > 0 and OS bus-lock detection was enabled (see Section 18.3.1.6). Other
debug exceptions do not modify this bit. To avoid confusion in identifying debug exceptions, software debug
exception handlers should set bit 11 to 1 before returning. (Software that never enables OS bus-lock detection
need not do this as DR6[11] = 1 following reset.) This bit is always 1 if the processor does not support OS bus
lock detection.
• BD (debug register access detected) flag (bit 13) — Indicates that the next instruction in the instruction
stream accesses one of the debug registers (DR0 through DR7). This flag is enabled when the GD (general
detect) flag in debug control register DR7 is set. See Section 18.2.4, “Debug Control Register (DR7),” for
further explanation of the purpose of this flag.
• BS (single step) flag (bit 14) — Indicates (when set) that the debug exception was triggered by the single
step execution mode (enabled with the TF flag in the EFLAGS register). The single-step mode is the highest
priority debug exception. When the BS flag is set, any of the other debug status bits also may be set.
• BT (task switch) flag (bit 15) — Indicates (when set) that the debug exception resulted from a task switch
where the T flag (debug trap flag) in the TSS of the target task was set. See Section 8.2.1, “Task-State
Segment (TSS),” for the format of a TSS. There is no flag in debug control register DR7 to enable or disable this
exception; the T flag of the TSS is the only enabling flag.
• RTM (restricted transactional memory) flag (bit 16) — Indicates (when clear) that a debug exception
(#DB) or breakpoint exception (#BP) occurred inside an RTM region while advanced debugging of RTM trans
actional regions was enabled (see Section 18.3.3). This bit is set for any other debug exception (including all
those that occur when advanced debugging of RTM transactional regions is not enabled). This bit is always 1 if
the processor does not support RTM.
Certain debug exceptions may clear bits 0-3. The remaining contents of the DR6 register are never cleared by the
processor. To avoid confusion in identifying debug exceptions, debug handlers should clear the register (except
bit 16, which they should set) before returning to the interrupted task.
18.2.4 Debug Control Register (DR7)
The debug control register (DR7) enables or disables breakpoints and sets breakpoint conditions (see Figure 18-1).
The flags and fields in this register control the following things:
• L0 through L3 (local breakpoint enable) flags (bits 0, 2, 4, and 6) — Enables (when set) the breakpoint
condition for the associated breakpoint for the current task. When a breakpoint condition is detected and its
associated Ln flag is set, a debug exception is generated. The processor automatically clears these flags on
every task switch to avoid unwanted breakpoint conditions in the new task.
• G0 through G3 (global breakpoint enable) flags (bits 1, 3, 5, and 7) — Enables (when set) the
breakpoint condition for the associated breakpoint for all tasks. When a breakpoint condition is detected and its
associated Gn flag is set, a debug exception is generated. The processor does not clear these flags on a task
switch, allowing a breakpoint to be enabled for all tasks.
• LE and GE (local and global exact breakpoint enable) flags (bits 8, 9) — This feature is not supported in
the P6 family processors, later IA-32 processors, and Intel 6 4 processors. When set, these flags cause the
processor to detect the exact instruction that caused a data breakpoint condition. For backward and forward
compatibility with other Intel processors, we recommend that the LE and GE flags be set to 1 if exact
breakpoints are required.
• RTM (restricted transactional memory) flag (bit 11) — Enables (when set) advanced debugging of RTM
transactional regions (see Section 18.3.3). This advanced debugging is enabled only if IA32_DEBUGCTL.RTM is
also set.
• GD (general detect enable) flag (bit 13) — Enables (when set) debug-register protection, which causes a
debug exception to be generated prior to any MOV instruction that accesses a debug register. When such a
condition is detected, the BD flag in debug status register DR6 is set prior to generating the exception. This
condition is provided to support in-circuit emulators.
When the emulator needs to access the debug registers, emulator software can set the GD flag to prevent
interference from the program currently executing on the processor.
The processor clears the GD flag upon entering to the debug exception handler, to allow the handler access to
the debug registers.
• R/W0 through R/W3 (read/write) fields (bits 16, 17, 20, 21, 24, 25, 28, and 29) — Specifies the
breakpoint condition for the corresponding breakpoint. The DE (debug extensions) flag in control register CR4
determines how the bits in the R/Wn fields are interpreted. When the DE flag is set, the processor interprets
bits as follows:
00 — Break on instruction execution only.
01 — Break on data writes only.
10 — Break on I/O reads or writes.
11 — Break on data reads or writes but not instruction fetches.
When the DE flag is clear, the processor interprets the R/Wn bits the same as for the Intel386™ and Intel486™
processors, which is as follows:
00 — Break on instruction execution only.
01 — Break on data writes only.
10 — Undefined.
11 — Break on data reads or writes but not instruction fetches.
• LEN0 through LEN3 (Length) fields (bits 18, 19, 22, 23, 26, 27, 30, and 31) — Specify the size of the
memory location at the address specified in the corresponding breakpoint address register (DR0 through DR3).
These fields are interpreted as follows:
00 — 1-byte length.
01 — 2-byte length.
10 — Undefined (or 8 byte length, see note below).
11 — 4-byte length.
If the corresponding RWn field in register DR7 is 00 (instruction execution), then the LENn field should also be 00.
The effect of using other lengths is undefined. See Section 18.2.5, “Breakpoint Field Recognition,” below.
For Pentium® 4 and Intel® Xeon® processors with a CPUID signature corresponding to family 15
(model 3, 4, and 6), break point conditions permit specifying 8-byte length on data read/write with
an of encoding 10B in the LENn field.
Encoding 10B is also supported in processors based on Intel Core microarchitecture or enhanced
Intel Core microarchitecture, the respective CPUID signatures corresponding to family 6, model 15,
and family 6, DisplayModel value 23 (see the CPUID instruction in Chapter 3, “Instruction Set
Reference, A-L,” in the Intel® 6 4 and IA-32 Architectures Software Developer’s Manual, Volume
2A). The Encoding 10B is supported in processors based on Intel Atom® microarchitecture, with
CPUID signature of family 6, DisplayModel value 1CH. The encoding 10B is undefined for other
processors.
hardware breakpoint在CPU启用保护模式后，地址是指线性地址(可以等同于虚拟地址)。
线性地址是在保护模式下，分页机制开启或关闭时使用的地址。在分页机制关闭时，线性地址直接映射到物理地址；在分页机制开启时，线性地址需要通过页表转换成物理地址。
当明确到被破坏数据的虚拟地址后，便可以利用perf启用hardware breakpoint功能了。
按照 perf 帮助描述
a hardware breakpoint event in the form of
\mem:addr[/len][:access] where addr is the address in
memory you want to break in. Access is the memory access
type (read, write, execute) it can be passed as follows:
\mem:addr[:[r][w][x]]. len is the range, number of bytes
from specified addr, which the breakpoint will cover. If
you want to profile read-write accesses in 0x1000, just
set mem:0x1000:rw. If you want to profile write accesses
in [0x1000~1008), just set mem:0x1000/8:w.
如下是一个例子，对于虚拟地址0xffff89b74be6bfe0起始的8字节范围内的写操作，都将被perf记录，-ag表示保存写时的call stack
perf record -e mem:0xffff89b74be6bfe0/8:w -ag
当内存被踩事件发生后，ctrl+c停止perf（或者killall -2 -w perf），perf便会停止并保存log到perf.data.
使用perf script命令便解析perf.data,如下：
systemd-journal 273 [003] 616.7576 41: 1 mem:0xffff89b74be6bfe0:
ffffffffc0dd7a84 mytest_start_xmit+0x20 (/lib/modules/5.19.0-rc1+/kernel/drivers/net/ethernet/mytest/mytest.ko)
ffffffffc0dd5af3 mytest_tlv_iter+0x73 (/lib/modules/5.19.0-rc1+/kernel/drivers/net/ethernet/mytest/mytest.ko)
ffffffffc0e032ba mytest_pci_tasklet+0x1a (/lib/modules/5.19.0-rc1+/kernel/drivers/net/ethernet/mytest/mytest.ko)
ffffffffa66a2ecd tasklet_action_common.isra.22+0x6d ([kernel.kallsyms])
ffffffffa66a300d tasklet_action+0x2d ([kernel.kallsyms])
ffffffffa74000f7 __softirqentry_text_start+0xf7 ([kernel.kallsyms])
ffffffffa66a358e irq_exit_rcu+0x9e ([kernel.kallsyms])
ffffffffa71dd896 common_interrupt+0x66 ([kernel.kallsyms])
ffffffffa7200eec asm_common_interrupt+0x2c ([kernel.kallsyms])
9a299 malloc+0x1b9 (/usr/lib/x86_6 4-linux-gnu/libc-2.31.so)
利用gdb mytest.ko后，执行info line *(mytest_wmi_tlv_svc_rdy_ext_parse+0x214)便可以得出代码文件行号。
(gdb) info line *(mytest_start_xmit+0x20)
Line 408 of "/home/mytest/drivers/net/ethernet/mytest/my.c" starts at address 0xbe58 <mytest_start_xmit+25>
and ends at 0xbe6 4 <mytest_start_xmit+37>.
(gdb) disassemble 0xbe58
Dump of assembler code for function mytest_start_xmit:
0x000000000000be58 <+25>: movzwl 0x8c(%rdi),%eax
0x000000000000be5f <+32>: mov %ax,0xa(%rsp)
0x000000000000be6 4 <+37>: movzwl %ax,%eax
0x000000000000be67 <+40>: imul $0x460,%rax,%rbp
0x000000000000be6e <+47>: add 0xad8(%rsi),%rbp
0x000000000000be75 <+54>: mov 0x3c0(%rsi),%rcx
在调试器attach后，也可以使用调试器命令启用hardware breakpoint.
linux gdb命令：
hbreak -- Set a hardware assisted breakpoint
watch -- Set a watchpoint for an expression
windows windbg命令：ba[ID] Access Size [Options] [Address [Passes]] ["CommandString"]
按照CPU手册说明，hardware breakpoint是占用寄存器DR0->DR7, 其数量是有限的，所以同时启用的hardware breakpoint的数量受限于寄存器数量，
不像software breakpoint没有数量限制。
