The most usual way to start gdb is with one argument, specifying an executable program:
gdb program
You can also start with both an executable program and a core file specified:
gdb program core
You can, instead, specify a process ID as a second argument, if you want to debug a running process:
gdb program 1234
would attach gdb to process 1234.
You can optionally have gdb pass any arguments after the executable file to the inferior using —args. This option stops option processing.
gdb —args gcc -O2 -c foo.c

To exit gdb, use the quit command (abbreviated q), or type an end-of-file character (usually Ctrl-d). If you do not supply expression, gdb will terminate normally; otherwise it will terminate using the result of expression as the error code.

An interrupt (often Ctrl-c) does not exit from gdb, but rather terminates the action of any gdb command that is in progress and returns to gdb command level. It is safe to type the interrupt character at any time because gdb does not allow it to take effect until a time when it is safe.

If you need to execute occasional shell commands during your debugging session, there is no need to leave or suspend gdb; you can just use the shell command.
shell command-string Invoke a standard shell to execute command-string.
The utility make is often needed in development environments. You do not have to use the shell command for this purpose in gdb:
make make-args Execute the make program with the specified arguments. This is equivalent to ‘shell make make-args’.

Command Completion
you might want to set a breakpoint on a subroutine whose name begins with ‘make’, but when you type b
make_TAB gdb just sounds the bell. Typing TAB again displays all the function names in
your program that begin with those characters, for example:
(gdb) b make TAB
gdb sounds bell; press TAB again, to see:
make_a_section_from_file make_environ
make_abs_section make_function_type

gcc, the gnu C/C++ compiler, supports ‘-g’ with or without ‘-O’, making it possible
to debug optimized code. We recommend that you always use ‘-g’ whenever you compile
a program. You may think your program is correct, but there is no sense in pushing your
luck.

Use the run command to start your program under gdb. The arguments to your program can be specified by the arguments of the run command.
The ‘start’ command does the equivalent of setting a temporary breakpoint
at the beginning of the main procedure and then invoking the ‘run’ command.

attach process-id This command attaches to a running process—one that was started outside
gdb.The first thing gdb does after arranging to debug the specified process is to stop it.

When you have finished debugging the attached process, you can use the detach
command to release it from gdb control. Detaching the process continues its
execution.

On certain operating systems, gdb is able to save a snapshot of a program’s state, called
a checkpoint, and come back to it later.

Thus, if you’re stepping thru a program and you think you’re getting close to the point
where things go wrong, you can save a checkpoint. Then, if you accidentally go too far and
miss the critical statement, instead of having to restart your program from the beginning,
you can just go back to the checkpoint and start again from there.
This can be especially useful if it takes a lot of time or steps to reach the point where
you think the bug occurs.
checkpoint
Save a snapshot of the debugged program’s current execution state. The
checkpoint command takes no arguments, but each checkpoint is assigned
a small integer id, similar to a breakpoint id.
info checkpoints
restart checkpoint-id
delete checkpoint checkpoint-id