|
 |
|
| |
|
|
Red Hat Enterprise Linux 9 Essentials Book now available.
Purchase a copy of Red Hat Enterprise Linux 9 (RHEL 9) Essentials Red Hat Enterprise Linux 9 Essentials Print and eBook (PDF) editions contain 34 chapters and 298 pages
|
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 (e.g. 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 (e.g. stop running code when it reaches a specified area of interest to the programmer).
-
Detect access to particular areas of memory (e.g. 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:
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, i.e. 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 -g flag.
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.
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 run command starts the execution of the program. If run is 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 print command displays the value of the argument given, and that argument can be almost anything relevant to the program. Usually, the argument is simply 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 beingtested.
bt (backtrace)-
The backtrace displays the chain of function calls used up until the exectuion was terminated. This is useful for investigating serious bugs (such as segmentation faults) with elusive causes.
l (list)-
When execution is stopped, the list command 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 continue command simply restarts the execution of the program, which will continue to execute until it encounters a breakpoint, runs into a specified or emergent condition (e.g. an error), or terminates.
n (next)-
Like continue, the next command also restarts execution; however, in addition to the stopping conditions implicit in the continue command, next will also halt execution at the next sequential line of code in the current source file.
s (step)-
Like next, the step command 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 finish command resumes executions, but halts when execution returns from a function.
Finally, two essential commands:
q (quit)-
This terminates the execution.
h (help)-
The help command provides access to its extensive internal documentation. The command takes arguments: help breakpoint (or h br), for example, shows a detailed description of the breakpoint command. Refer to the help output of each command for more detailed information.
|
|
|
