Go forward to Signals.
Go backward to Breakpoints.
Go up to Stopping.

Continuing and stepping
=======================

   "Continuing" means resuming program execution until your program
completes normally.  In contrast, "stepping" means executing just one
more "step" of your program, where "step" may mean either one line of
source code, or one machine instruction (depending on what particular
command you use).  Either when continuing or when stepping, your
program may stop even sooner, due to a breakpoint or a signal.  (If due
to a signal, you may want to use `handle', or use `signal 0' to resume
execution.  See Signals: Signals.)

`continue [IGNORE-COUNT]'
`c [IGNORE-COUNT]'
`fg [IGNORE-COUNT]'
     Resume program execution, at the address where your program last
     stopped; any breakpoints set at that address are bypassed.  The
     optional argument IGNORE-COUNT allows you to specify a further
     number of times to ignore a breakpoint at this location; its
     effect is like that of `ignore' (see Break conditions: Conditions.).

     The argument IGNORE-COUNT is meaningful only when your program
     stopped due to a breakpoint.  At other times, the argument to
     `continue' is ignored.

     The synonyms `c' and `fg' are provided purely for convenience, and
     have exactly the same behavior as `continue'.

   To resume execution at a different place, you can use `return'
(see Returning from a function: Returning.) to go back to the calling
function; or `jump' (see Continuing at a different address: Jumping.)
to go to an arbitrary location in your program.

   A typical technique for using stepping is to set a breakpoint (
see Breakpoints; watchpoints; and exceptions: Breakpoints.) at the
beginning of the function or the section of your program where a
problem is believed to lie, run your program until it stops at that
breakpoint, and then step through the suspect area, examining the
variables that are interesting, until you see the problem happen.

`step'
     Continue running your program until control reaches a different
     source line, then stop it and return control to GDB.  This command
     is abbreviated `s'.

          *Warning:* If you use the `step' command while control is
          within a function that was compiled without debugging
          information, execution proceeds until control reaches a
          function that does have debugging information.  Likewise, it
          will not step into a function which is compiled without
          debugging information.  To step through functions without
          debugging information, use the `stepi' command, described
          below.

     The `step' command now only stops at the first instruction of a
     source line.  This prevents the multiple stops that used to occur
     in switch statements, for loops, etc.  `step' continues to stop if
     a function that has debugging information is called within the
     line.

     Also, the `step' command now only enters a subroutine if there is
     line number information for the subroutine.  Otherwise it acts
     like the `next' command.  This avoids problems when using `cc -gl'
     on MIPS machines.  Previously, `step' entered subroutines if there
     was any debugging information about the routine.

`step COUNT'
     Continue running as in `step', but do so COUNT times.  If a
     breakpoint is reached, or a signal not related to stepping occurs
     before COUNT steps, stepping stops right away.

`next [COUNT]'
     Continue to the next source line in the current (innermost) stack
     frame.  This is similar to `step', but function calls that appear
     within the line of code are executed without stopping.  Execution
     stops when control reaches a different line of code at the
     original stack level that was executing when you gave the `next'
     command.  This command is abbreviated `n'.

     An argument COUNT is a repeat count, as for `step'.

     The `next' command now only stops at the first instruction of a
     source line.  This prevents the multiple stops that used to occur
     in swtch statements, for loops, etc.

`finish'
     Continue running until just after function in the selected stack
     frame returns.  Print the returned value (if any).

     Contrast this with the `return' command (*note Returning from a
     function: Returning.).

`u'
`until'
     Continue running until a source line past the current line, in the
     current stack frame, is reached.  This command is used to avoid
     single stepping through a loop more than once.  It is like the
     `next' command, except that when `until' encounters a jump, it
     automatically continues execution until the program counter is
     greater than the address of the jump.

     This means that when you reach the end of a loop after single
     stepping though it, `until' makes your program continue execution
     until it exits the loop.  In contrast, a `next' command at the end
     of a loop simply steps back to the beginning of the loop, which
     forces you to step through the next iteration.

     `until' always stops your program if it attempts to exit the
     current stack frame.

     `until' may produce somewhat counterintuitive results if the order
     of machine code does not match the order of the source lines.  For
     example, in the following excerpt from a debugging session, the `f'
     (`frame') command shows that execution is stopped at line `206';
     yet when we use `until', we get to line `195':

          (gdb) f
          #0  main (argc=4, argv=0xf7fffae8) at m4.c:206
          206                 expand_input();
          (gdb) until
          195             for ( ; argc > 0; NEXTARG) {

     This happened because, for execution efficiency, the compiler had
     generated code for the loop closure test at the end, rather than
     the start, of the loop--even though the test in a C `for'-loop is
     written before the body of the loop.  The `until' command appeared
     to step back to the beginning of the loop when it advanced to this
     expression; however, it has not really gone to an earlier
     statement--not in terms of the actual machine code.

     `until' with no argument works by means of single instruction
     stepping, and hence is slower than `until' with an argument.

`until LOCATION'
`u LOCATION'
     Continue running your program until either the specified location
     is reached, or the current stack frame returns.  LOCATION is any of
     the forms of argument acceptable to `break' (*note Setting
     breakpoints: Set Breaks.).  This form of the command uses
     breakpoints, and hence is quicker than `until' without an argument.

`stepi'
`si'
     Execute one machine instruction, then stop and return to the
     debugger.

     It is often useful to do `display/i $pc' when stepping by machine
     instructions.  This makes GDB automatically display the next
     instruction to be executed, each time your program stops.  
See Automatic display: Auto Display.

     An argument is a repeat count, as in `step'.

`nexti'
`ni'
     Execute one machine instruction, but if it is a function call,
     proceed until the function returns.

     An argument is a repeat count, as in `next'.