GDB is a very powerful command line debugger which many other debuggers, including DDD, are based on. Like Unix(tm) in general, it is not necessarily user friendly, but very powerful. If you choose to learn it, you will find it very powerful.
The documentation for gdb is very extensive and well done. There are both man pages and info pages. The info pages are the most complete. There is good help available using the "help" command.
To run a program with gdb, just do:
gdb program name
It helps if the program is compiled with debugging symbols (-g flag to gcc) and to be in the directory where the source code is.
Once started you will get the following prompt:
(gdb)
Usually you will want to start off by setting a break point at the main function and actually start running the program:
(gdb) break main Breakpoint 1 at 0x8048587: file vulnerable.c, line 78. (gdb) run Starting program: vulnerable Breakpoint 1, main (argc=1, argv=0xbffff914) at vulnerable.c:78 warning: Source file is more recent than executable. 78 unsigned int print_sp = false; (gdb)
To pass command line arguments to the program, before running it do:
(gdb) set args arguments
Where arguments are the arguments.
To step through a program, you can use the "next" and "step" commands. "next" will not step into functions while "step" will.
To see where you are in the code, use the "list" command.
You can get a listing of the function stack frames using the "bt" or back trace command. This will list which function you are in and what functions called it back to main.
You can move up and down in the listing using the "up" and "down" command.
Break points can be set using the "break" command. It takes as an argument either the line number or the function name where you want the break point set.
You can cause the program to execute until the next break point using the "continue" command.
The "print" command will print the value of a variable. The "display" command will cause the variable to be printed after each step you take.
You can examine arbitrary memory locations using the "x" command. Issue a "help x" for more information as this command is rather detailed.
Most modern user environments turn off core dumps as mostly users are not interested in them. To turn core dumps back on before executing a program, do the following:
ulimit -c unlimited
This changes the limit on the size of a core file to not be limited.
When a program crashes and dumps a core, it creates a file named "core" in it's working directory. This file contains a memory dump of the process that gdb and other debuggers can go through.
To debug a core file, do the following:
gdb program core
Where program is the program that dumped the core and core is the core file.
When debugging a program from a core file, you can only look at the contents of memory. This allows you to find out where the program terminated and what data it was working with. You will not be able to step through the program because it is not running anymore.