Google defines a debugger as:

• A computer program that assists in the detection and correction of errors in computer programs.

There is an important concept we must acknowledge here- a debugger is a program, just like the programs we've been writing.

But as a program, it works with other programs. It is a program for programs. See the depth there?

GDB, the GNU Debugger, is certainly not the only debugger in existence, but it is most likely among the most available general purpose debuggers we can get our hands on.

Learning one debugger, like GDB, well will introduce you to many important concepts that all debuggers share (some just may enable certain actions better than others, or be more specialized for certain tasks– but they all, as debuggers, share a common underlying functionality).

The prime value we are looking to get out of our debugger use is to aid us in finding (and therefore fixing) runtime and logical errors in programs we write. It is also a phenomenal investigative tool, allowing us to see what a particular piece of code is ACTUALLY doing, as far down as the assembly instructions, but in our case the line-by-line execution of our programs in C.

Common fundamental features a debugger may provide:

• stepping: the ability to comb over your running program a line at a time. Often referred to as “single step”- we can execute a line of code (much as an interpreter might), and analyze the state of variables. This is great for seeing if things are as they should be at various points in a program's execution (into a function, a particular iteration of a loop, etc.)
• viewing data: as indicated in stepping- in the debugger we can view the state of any existing variable or memory location at any stage of the program's execution.
• breakpoints: the magic that makes single stepping even more useful. A breakpoint is us communicating to the debugger where we'd like it to pause execution so that we may check out the current state of things. By strategically setting breakpoints throughout a program, we can run through the sections of code we're not interested, then break to analyze areas of particular interest.
• continue: the cessation of single step mode, when we wish to resume regular execution (until the next breakpoint is encountered).
• manipulating data: we also have the ability to modify existing data, such as variables… setting them to desired values and watching what will happen in our code.

There are many, many more features, but we're just getting started, and these are by far the most useful for us in our endeavors.

To take full advantage of the debugging environment, we must instruct the compiler at compile time to include debug-specific information.

We can do this by adding a -g to the compiler's argument list. It can go anywhere on the command-line, provided where it is placed doesn't violate any syntax rules of the other arguments.

$ gcc -g -o hello hello.c

A debugger acts as a sort of wrapper when running a program. It runs the desired program within it, so that we can use the debugger's features to better study what is going on.

As such, we need to start a debugging session as follows:

$ gdb ./hello

Note we run the program as usual, but we take care to prefix it with “gdb” (so gdb knows what program to run).

If your program is segfaulting, a quick and easy way to use the debugger is to let it run as normal, and when the program crashes it will provide you with information on where the problem took place. In some cases, this can be enough to identify and fix problems (more involved use of the debugger requires you to know increasingly more specifically where the problem is taking place, so starting off with strategies like this will only help you in further debugging efforts).

Let's take a program that will segfault on execution:

#include <stdio.h>
 
int main()
{
    char c, *s, len = 0;
    while ((*(s+len++) = fgetc(stdin)) != '\n');
    fprintf(stdout, "%s\n", s);
    return(0);
}

Type this in and name it (I'll use input.c as my example name).

Compile it with debugging support:

$ gcc -g -o input input.c
$

The debugger is only useful with code free of syntax errors (because it requires the code to successfully compile to work). If your code does not compile, you cannot use the debugger to help fix the problem.

Now, let us start gdb with input as our debug target:

$ gdb ./input

A smallish banner message will appear, and at the very bottom will be a “(gdb)” prompt. This is where you'll be entering various commands.

For starters, let us just run the program and see what happens. We do this by issuing the “run” command at the gdb prompt:

(gdb) run