Breakpoints must be located and resolved by the debugger before they can be hit. When a breakpoint is hit in the module, the debugger halts program execution and displays the state of the program in the Debug perspective.
To hit a breakpoint during a debug session, the debugger must first load the symbols for an executable module and then attempt to resolve the breakpoints within the loaded module. Any module listed into the Executables view is available for loading by a debug session. If a module is not present in the Executable view you'll need to import it before the debugger to load and resolve any breakpoints within that module.
You set a breakpoint on any executable line of code that the debugger can resolve. Lines containing comments and other non executable code cannot be assigned a breakpoint as they are normally stripped from the compiled binary. Carbide helps by preventing you from setting a breakpoint on a non-compilable line of code.
When the debugger attempts to resolve a breakpoint the possible results are shown in Table 1.
Type | Icon | State | Explanation |
---|---|---|---|
Enabled | ![]() |
Unresolved |
The breakpoint is enabled but the symbols for the module are not loaded or the breakpoint was not able to be set within the current function.Breakpoint icon remains in unflagged state indicating unresolved status. If the breakpoint has been set in the source file but not resolved:
|
![]() |
Resolved |
The breakpoint is currently enabled, the symbols for the module are loaded, and the breakpoint located in the executable being debugged. The debugger halts program execution at an enabled breakpoint.
|
|
Disabled | ![]() |
Unresolved |
Indicates that the breakpoint is currently disabled but not located in the executable during a debug session. The debugger does not halt program execution at a disabled breakpoint. |
![]() |
Resolved |
Indicates that the breakpoint is currently disabled and resolved for the source line. The debugger does not halt program execution at a disabled breakpoint. |