Here is a quick start tutorial for gdb:

/* test.c  */
/* Sample program to debug.  */
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char **argv) 
{
  if (argc != 3)
    return 1;
  int a = atoi (argv[1]);
  int b = atoi (argv[2]);
  int c = a + b;
  printf ("%d\n", c);
  return 0;
}

Compile with the -g3 option. g3 includes extra information, such as all the macro definitions present in the program.

gcc -g3 -o test test.c

Load the executable, which now contain the debugging symbols, into gdb:

gdb --annotate=3 test.exe 

Now you should find yourself at the gdb prompt. There you can issue commands to gdb. Say you like to place a breakpoint at line 11 and step through the execution, printing the values of the local variables - the following commands sequences will help you do this:

(gdb) break test.c:11
Breakpoint 1 at 0x401329: file test.c, line 11.
(gdb) set args 10 20
(gdb) run
Starting program: c:\Documents and Settings\VMathew\Desktop/test.exe 10 20
[New thread 3824.0x8e8]

Breakpoint 1, main (argc=3, argv=0x3d5a90) at test.c:11
(gdb) n
(gdb) print a
$1 = 10
(gdb) n
(gdb) print b
$2 = 20
(gdb) n
(gdb) print c
$3 = 30
(gdb) c
Continuing.
30

Program exited normally.
(gdb) 

In short, the following commands are all you need to get started using gdb:

break file:lineno - sets a breakpoint in the file at lineno.
set args - sets the command line arguments.
run - executes the debugged program with the given command line arguments.
next (n) and step (s) - step program and step program until it 
                        reaches a different source line, respectively. 
print - prints a local variable
bt -  print backtrace of all stack frames
c - continue execution.

Type help at the (gdb) prompt to get a list and description of all valid commands.

Besides things that have already been posted i also use:

• a .gdbinit file for STL containers
• signal SIGNAL noprint nostop for some custom signals that are of no real interest when debugging
• C-Casts to dereference pointers
• catchpoints (catch throw, catch catch)
• condition for conditional break- and watchpoints
• rarely gdbserver for remote debugging
• gdb program coredump, for those embarassing segfaults ;)

PS: One reason i personally love gdb btw. is that it supports tab-completion for nearly everything (gdb commands, symbols in the symbol table, functions, memberfunctions etc.). This is a fairly good productivity boost in my opinion.

Summarizing the comments (before anyone else does :).

Your executable file is missing the symbolic information that gdb needs to display the relevant source code. You need to add the -g option to the compile command and produce a new executable. Then re-run your failing test to produce a new core file. gdb with this executable and core will be able to show you the stack of function calls using backtrace.

In a makefile, the easiest way to do this is to add (to) the CFLAGS variable which is used with the implicit .o.c rule.

CFLAGS= -g -Wall -Wextra

You can also add this directly to the command-line (assuming a decent shell :). This sets the value as an environment variable during the execution of the make command (and sub-commands).

$ CFLAGS='-g -Wall -Wextra' make

I'd actually recommend you add this to your bash .profile, so you always get the most information from the compiler.

CFLAGS='-Wall -Wextra'

Then, when you need it, put this in the makefile to make a debuggable executable:

CFLAGS+= -g