4.3. GDB
Fundamentally, like most debuggers, GDB manages the execution of compiled code in a very closely controlled environment. This environment makes possible the following fundamental mechanisms necessary to the operation of GDB:
- Inspect and modify memory within the code being debugged (for example, reading and setting variables).
- Control the execution state of the code being debugged, principally whether it's running or stopped.
- Detect the execution of particular sections of code (for example, stop running code when it reaches a specified area of interest to the programmer).
- Detect access to particular areas of memory (for example, stop running code when it accesses a specified variable).
- Execute portions of code (from an otherwise stopped program) in a controlled manner.
- Detect various programmatic asynchronous events such as signals.
The operation of these mechanisms rely mostly on information produced by a compiler. For example, to view the value of a variable, GDB has to know:
- The location of the variable in memory
- The nature of the variable
This means that displaying a double-precision floating point value requires a very different process from displaying a string of characters. For something complex like a structure, GDB has to know not only the characteristics of each individual elements in the structure, but the morphology of the structure as well.
GDB requires the following items in order to fully function:
- Debug Information
- Much of GDB's operations rely on a program's debug information. While this information generally comes from compilers, much of it is necessary only while debugging a program, that is, it is not used during the program's normal execution. For this reason, compilers do not always make that information available by default — GCC, for instance, must be explicitly instructed to provide this debugging information with the
-gflag.To make full use of GDB's capabilities, it is highly advisable to make the debug information available first to GDB. GDB can only be of very limited use when run against code with no available debug information. - Source Code
- One of the most useful features of GDB (or any other debugger) is the ability to associate events and circumstances in program execution with their corresponding location in source code. This location normally refers to a specific line or series of lines in a source file. This, of course, would require that a program's source code be available to GDB at debug time.
4.3.1. Simple GDB
GDB literally contains dozens of commands. This section describes the most fundamental ones.
br(breakpoint)- The breakpoint command instructs GDB to halt execution upon reaching a specified point in the execution. That point can be specified a number of ways, but the most common are just as the line number in the source file, or the name of a function. Any number of breakpoints can be in effect simultaneously. This is frequently the first command issued after starting GDB.
r(run)- The
runcommand starts the execution of the program. Ifrunis executed with any arguments, those arguments are passed on to the executable as if the program has been started normally. Users normally issue this command after setting breakpoints.
Before an executable is started, or once the executable stops at, for example, a breakpoint, the state of many aspects of the program can be inspected. The following commands are a few of the more common ways things can be examined.
p(print)- The
printcommand displays the value of the argument given, and that argument can be almost anything relevant to the program. Usually, the argument is the name of a variable of any complexity, from a simple single value to a structure. An argument can also be an expression valid in the current language, including the use of program variables and library functions, or functions defined in the program being tested. bt(backtrace)- The
backtracedisplays the chain of function calls used up until the execution was terminated. This is useful for investigating serious bugs (such as segmentation faults) with elusive causes. l(list)- When execution is stopped, the
listcommand shows the line in the source code corresponding to where the program stopped.
The execution of a stopped program can be resumed in a number of ways. The following are the most common.
c(continue)- The
continuecommand restarts the execution of the program, which will continue to execute until it encounters a breakpoint, runs into a specified or emergent condition (for example, an error), or terminates. n(next)- Like
continue, thenextcommand also restarts execution; however, in addition to the stopping conditions implicit in thecontinuecommand,nextwill also halt execution at the next sequential line of code in the current source file. s(step)- Like
next, thestepcommand also halts execution at each sequential line of code in the current source file. However, if execution is currently stopped at a source line containing a function call, GDB stops execution after entering the function call (rather than executing it). fini(finish)- Like the aforementioned commands, the
finishcommand resumes executions, but halts when execution returns from a function.
Finally, two essential commands:
q(quit)- This terminates the execution.
h(help)- The
helpcommand provides access to its extensive internal documentation. The command takes arguments:help breakpoint(orh br), for example, shows a detailed description of thebreakpointcommand. See thehelpoutput of each command for more detailed information.
