Stop where values cross a boundary
If a program prints a wrong total, stopping only at the print function may be too late. First confirm the bad output, then stop at the entry to the function that computes it. If the input is already wrong, move toward the caller. If the input is correct but the return value is wrong, investigate inside the function. A breakpoint is most useful as a boundary between two explanations, rather than as a way to read as much code as possible. Decide what should be true when execution reaches it.
Choose a location format
A function name such as main or accumulate is readable and can remain meaningful after rebuilding. A source location such as counter.c:10 is convenient near a particular calculation, although GDB may move it to a nearby executable location if the requested line has no instruction. An address breakpoint uses a leading asterisk, for example *0x140001000. This is useful without symbols, but the same number is not guaranteed to refer to the same instruction in another run or build. Confirm the current module and instruction before relying on an address.
Change the question when a breakpoint fires too often
A breakpoint inside a busy loop can stop thousands of times. Instead of repeatedly pressing Continue, ask whether the first iteration is wrong, whether a particular input causes failure, or whether the number of calls is itself unexpected. DBG Desk currently adds and deletes basic breakpoints; it does not have a condition or hit-count editor. You can use a separate GDB session for those features, or reduce the input so repeated stops are manageable. Knowing the available controls avoids searching the interface for functionality that is not present.
Use each stop to choose the next one
Check the current function, call stack, and registers relevant to the input. Different callers can reach the same function with different assumptions. Remove breakpoints that no longer test a useful hypothesis; otherwise old stops make the next result hard to interpret. Comparing a normal input and a failing input at the same boundary often reveals the first meaningful difference. Move the next breakpoint inside that smaller interval.
Example: an incorrect sum
In counter.c, stop at accumulate and compare its input and output. An input of 0 should return 1, and an input of 1 should return 4. Then check whether the caller adds each return value exactly once. Too many calls suggest a loop condition problem; correct inputs with wrong returns suggest a problem inside the calculation. Write down the expected value for each stop so that the observation answers a specific question.