Debugging with GDB (September 2007)

46 Debugging with GDB

(gdb) until

195 for ( ; argc > 0; NEXTARG) {

This happened because, for execution eﬃciency, the compiler had ge nerated

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 speciﬁed location is reached,

or the current stack frame returns. location is any of the forms of argument

acceptable to break (see Section 5.1.1 [Setting breakpoints], page 33). This form

of the command uses breakpoints, and hence is quicker than until without an

argument.

stepi

stepi arg

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 Section 8.6 [Automatic display], page 68.

An argument is a repeat count, as in step.

nexti

nexti arg

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.

5.3 Signals

A signal is an asynchronous event that c an happen in a program. The operating system

deﬁnes the possible kinds of signals, and gives each kind a name and a number. For example,

in Unix SIGINT is the signal a program gets when you type an interrupt character (often C-

c); SIGSEGV is the signal a program gets from referencing a place in memory far away from

all the areas in use; SIGALRM occurs when the alarm clock timer goes oﬀ (which happens

only if your program has requested an alarm).

Some signals, including SIGALRM, are a normal part of the functioning of your program.

Others, such as SIGSEGV, indicate errors; these signals are fatal (they kill your program

immediately) if the program has not speciﬁed in advance some other way to handle the

signal. SIGINT does not indicate an error in your program, but it is normally fatal so it can

carry out the purpose of the interrupt: to kill the program.