Setting Source-Level Breakpoints

Typically, you set and clear breakpoints before you start a process. To set a source-level breakpoint, select a line number in the Source view.

Source View Line Number Indicators
  • A bold line number denotes that the compiler generated one or more line number symbols for the source line. Multiple symbols might be within a single image file, for example on a "for" loop statement. Or, the line number symbols might be spread across multiple image files if the source file was compiled into the executable, shared libraries, and/or CUDA code.

  • No bold indicates that the compiler did not generate any line number symbols for the source line. However, you can still set a sliding or pending breakpoint at the line, which is useful if you know that code for that line will be dynamically loaded at runtime, for example, in a dynamically loaded shared library or a CUDA kernel launch.

For example, Figure 22 illustrates that source lines 48 and 49 both have line number symbols. Lines with no bold indicate that no executable code exists at those source lines yet (although you can set a sliding or pending breakpoint at those lines, discussed in Pending Breakpoints and Sliding Breakpoints ).

Figure 22. Possible breakpoint locations in the Source view

Setting the Breakpoint

Set a breakpoint either by:

  • Clicking directly on the line number in the Source view, or

  • Right-clicking on the line number and using the context menu, or

  • Clicking on a line in the Source View and then selecting the Action Points > Set Breakpoint menu item.

Once set, the breakpoint displays in the Action Points menu.

Figure 23. Set a breakpoint

Add any number of breakpoints before you run your program. (You can add or remove breakpoints at any point during your program's execution.)

Setting a breakpoint on a line may cause that breakpoint to appear at many code locations. For example, setting a breakpoint on a line of templated code may cause the breakpoint to appear at all instances of that template.

When you set a breakpoint or barrier point, it is defined by a breakpoint expression, also called a breakpoint specification, displayed in the Action Points tab for that breakpoint, or entered into the CLI (if created using the CLI). For more information, see dbreak.

Sliding Breakpoints

If you try to set a breakpoint in the Source view at a location with no bolded line, i.e., if there are no line number symbols for that source code line yet, TotalView automatically “slides” the breakpoint to the next line number in the source file that does have a line number symbol.

For example, in Figure 24, a breakpoint was set at line 45 and slid to line 48 where there was a line number symbol. The Source view then displayed a hollow red box indicating that it slid, along with a solid red box at the slid location.

Figure 24. Sliding breakpoint

The Action Points Location column always displays the full breakpoint expression (in brackets). It also displays the "best" source file and line number it can currently find. TotalView does not change the original breakpoint expression, in the event that dynamically loaded code would be a better match later.

The breakpoint expression—pointing to line 45—is displayed in the Actions Points Location column as well as the location of the actual breakpoint at line 48. Retaining the original expression supports the situation in which a library that is dynamically loaded does have line number symbols at that location. As the program runs and dynamically loads code, TotalView reevaluates the breakpoint expressions, factoring in any new line number symbols it finds. If better-matching line number information is found, the address blocks in the breakpoint are updated to add the addresses of the new line number symbols, and possibly disable or invalidate old address blocks. This ensures that the breakpoint triggers for the most relevant source line.

If TotalView cannot find a line number symbol following the line specified in the breakpoint expression, it creates a pending breakpoint. For example, this could occur when setting a breakpoint at the end of a source file. See Pending Breakpoints for information.

Dynamic Code Loading Example

To see how this works, consider a program that will load code at runtime, such as when debugging CUDA code running on a GPU.

Figure 25 illustrates a breakpoint set at line 91 that has slid to line 134:

Figure 25. Sliding breakpoints when dynamically loading code

Once the program is running and the CUDA code is loaded, TotalView recalculates the breakpoint expression and is able to plant a breakpoint at line 91 in the CUDA code, which is an exact match for the breakpoint expression:

TotalView then disables the slid breakpoint at line 134 since it found a better match. Verify this using the dactions command in the CLI:

1.<> dactions -full -block_lines
1 shared action point for group 3:
1 [/home/totalview/cuda-example/tx_cuda_matmul.cu#91] Enabled
Address 0: [Disabled] MatMulKernel+0x18, tx_cuda_matmul.cu#134 (0x0040372d)
Address 1: [Enabled] MatMulKernel+0xae0, tx_cuda_matmul.cu#91 (Location not mapped)
Share in group: true
Stop when hit: process