- Hardware Breakpointsare implemented using the DRx architectural breakpoint registers described in the Intel® 64 and IA-32 Architectures Software Developer Manuals. They have the advantage of being usable directly at reset, being non-volatile, and being usable with flash or other read-only memory. The downside is that they are a finite resource.
- Software Breakpointsrequire modifying system memory as they are implemented by replacing the opcode at the desired location with a special instruction. This makes them an unlimited resource, but the memory dependency mean you cannot install them prior to a module being loaded in memory, and if the target software overwrites that memory then they will become invalid.
- CPU Reset clears all debug features, except for reset break. This means, for example, that user-specified breakpoints will be invalid until the target halts once after reset. Note that this halt can be due to either a reset-break, or due to a user-initiated halt. In either case, the debugger restores the necessary debug features.
- SMM Entry/exit disables/re-enables breakpoints. This means you cannot specify a breakpoint in SMRAM while halted outside of SMRAM. If you wish the break within SMRAM, you must first halt at the SMM entry-break and manually apply the breakpoint. Alternatively, you can patch the BIOS to re-enable breakpoints when entering SMM, but this requires the ability to modify the BIOS, which cannot be used in production code.