Hardware program breakpoints

The number of available hardware breakpoints depends on the CPU. Software breakpoints are in fact set by replacing the instruction to be breakpointed with a breakpoint instruction. The breakpoint instruction is present in most CPUs, and usually as short as the shortest instruction, so only one byte on x86 0xcc, INT 3. On Cortex-M CPUs, instructions are 2 or 4 bytes, so the breakpoint instruction is a 2 byte instruction.

A lot of embedded systems have the program located in flash memory. Here it is not so easy to exchange the instruction, as the flash needs to be reprogrammed, so hardware breakpoints are used primarily. Most debug probes support only hardware breakpoints if the program is located in flash memory. However, some such as SEGGER's J-Link allow reprogramming the flash memory with breakpoint instruction and aso allow an unlimited number of software breakpoints even when debugging a program located in flash.

More info about software breakpoints in flash memory. In addition to the answers above, it is also important to note that while software breakpoints overwrite specific instructions in the program to know where to stop, the more limited number of hardware breakpoints are actually part of the processor.

Justin Seitz in his book Gray Hat Python points out that the important difference here is that by overwriting instructions, software breakpoints actually change the CRC of the file, and so any sort of program such as a piece of malware which calculates its CRC can change its behavior in response to breakpoints being set, whereas with hardware breakpoints it is less obvious that the debugger is stopping and stepping through certain chunks of code.

In brief, hardware breakpoints make use of dedicated registers and hence are limited in number. These can be set on both volatile and non volatile memory. Software breakpoints are set by replacing the opcode of instruction in RAM memory with breakpoint instruction. These can be set only in RAM memory Flash memory is not feasible to be written and are not limited. This article provides good explanation about breakpoints.

The "software" alternative is to single step the program , which is very slow. Compare that to regular breakpoints, where at least the software implementation inserts and int3 instruction and lets the program run, so you only pay overhead when a breakpoint is hit.

Hardware vs. Software Breakpoints The debugger can use both hardware and software breakpoints, each of these has strengths and weaknesses:. 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 Breakpoints require 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. Specific examples include:. CPU Reset will clear 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 will restore the necessary debug features. Once these breakpoints are set, they are treated just like the breakpoints set with the break command. You can delete them, disable them, or make them conditional the same way as any other breakpoint. The syntax of the regular expression is the standard one used with tools like grep. There is an implicit. The rbreak command can be used to set breakpoints in all the functions in a program, like this:.

If rbreak is called with a filename qualification, it limits the search for functions matching the given regular expression to the specified file. This can be used, for example, to set breakpoints on every function in a given file:. The colon separating the filename qualifier from the regex may optionally be surrounded by spaces.

Print a table of all breakpoints, watchpoints, and catchpoints set and not deleted. Optional argument n means print information only about the specified breakpoint s or watchpoint s or catchpoint s.

For each breakpoint, following columns are printed:. Where the breakpoint is in your program, as a memory address. See below for details. Where the breakpoint is in the source for your program, as a file and line number. For a pending breakpoint, the original string passed to the breakpoint command will be listed as it cannot be resolved until the appropriate shared library is loaded in the future. The info break command shows the condition on the line following the affected breakpoint, together with its condition evaluation mode in between parentheses.

Breakpoint commands, if any, are listed after that. A pending breakpoint is allowed to have a condition specified for it. The condition is not parsed for validity until a shared library is loaded that allows the pending breakpoint to resolve to a valid location. This is especially useful in conjunction with the ignore command.

You can ignore a large number of breakpoint hits, look at the breakpoint info to see how many times the breakpoint was hit, and then run again, ignoring one less than that number. This will get you quickly to the last hit of that breakpoint. For a breakpoints with an enable count xref greater than 1, info break also displays that count. GDB allows you to set any number of breakpoints at the same place in your program. There is nothing silly or meaningless about this.

When the breakpoints are conditional, this is even useful see Break Conditions. It is possible that a breakpoint corresponds to several locations in your program. Examples of this situation are:. A breakpoint with multiple locations is displayed in the breakpoint table using several rows—one header row, followed by one row for each breakpoint location.

The rows for individual locations contain the actual addresses for locations, and show the functions to which those locations belong. The number column for a location is of the form breakpoint-number. You cannot delete the individual locations from a breakpoint. However, each location can be individually enabled or disabled by passing breakpoint-number. Disabling or enabling the parent breakpoint see Disabling affects all of the locations that belong to that breakpoint.

Shared libraries can be loaded and unloaded explicitly, and possibly repeatedly, as the program is executed. To support this use case, GDB updates breakpoint locations whenever any shared library is loaded or unloaded. Typically, you would set a breakpoint in a shared library at the beginning of your debugging session, when the library is not loaded, and when the symbols from the library are not available.

When you try to set breakpoint, GDB will ask you if you want to set a so called pending breakpoint —breakpoint whose address is not yet resolved. After the program is run, whenever a new shared library is loaded, GDB reevaluates all the breakpoints. When a newly loaded shared library contains the symbol or line referred to by some pending breakpoint, that breakpoint is resolved and becomes an ordinary breakpoint.

When a library is unloaded, all breakpoints that refer to its symbols or source lines become pending again. This logic works for breakpoints with multiple locations, too. Hardware breakpoints are the fastest and the most used breakpoint. Hardware breakpoints have a problem.

A microcontroller will typically only have 2 — 4 comparators which means once they are used up, no more breakpoints can be added! Thankfully, there are also software breakpoints. A software breakpoint is typically an instruction that temporarily replaces an instruction in RAM that is either an illegal instruction and causes a fault or is designed to cause the application to break. When the CPU reaches this instruction, it halts execution. Software breakpoints can only be used for application code that reside in RAM.

The reason is that an instruction is literally swapped out for the breakpoint instruction. Once a developer steps past the BKPT, the originally code that would have executed at that location is ran. Developers can use a nearly endless number of software breakpoints but the major issue is that again they are designed for code running in RAM.