Running programs under GDB

To run a program under GDB, you must first generate debugging information when you compile it. You may start GDB with its arguments, if any, in an environment of your choice. You may redirect your program's input and output, debug an already running process, or kill the process being debugged.

Compiling for debugging
Debugging information is stored in the object file; it describes the data type of each variable or function and the correspondence between source line numbers and addresses in the executable code.
Setting the target
Starting your program
The execution of a program is affected by certain information it receives from its superior. GDB provides ways to specify this information, which you must do before starting your program. (You can change it after starting your program, but such changes affect your program the next time you start it.)
Your program's arguments
The arguments to your program can be specified by the arguments of the run command.
Your program's environment
The environment consists of a set of environment variables and their values.
Your program's input and output
By default, the program you run under GDB does input and output to the same terminal that GDB uses. GDB switches the terminal to its own terminal modes to interact with you, but it records the terminal modes your program was using and switches back to them when you continue running your program.
Debugging an already-running process
To use attach, you must have permission to send the process a signal.
Killing the process being debugged
This command is useful if you wish to debug a core dump instead of a running process. GDB ignores any core dump file while your program is running.
Debugging programs with multiple threads
In QNX Neutrino, a single program may have more than one thread of execution. Each thread has its own registers and execution stack.
Debugging programs with multiple processes
GDB has no special support for debugging programs that create additional processes using the fork() function. When a program forks, GDB continues to debug the parent process, and the child process runs unimpeded. If you've set a breakpoint in any code that the child then executes, the child gets a SIGTRAP signal, which (unless it catches the signal) causes it to terminate.

Related concepts

Debug a Program in the IDE (IDE User's Guide)

Related reference

gdb

Parent topic: Using GDB