GDB

Introduction
GDB, or the (G)NU (D)e(B)ugger, is a program used to find run time errors that normally involve memory corruption. First off, let's take a look at what debugging entails. One of the main things you must do in order to debug a program is to the program with. This prevents the stripping of debug symbols. Why are programs stripped by default? The reason is the same as that for having gzipped man pages - saving space. Here's how the size of a program varies with and without debug symbol stripping.

Just for reference, bad_code is the program we'll be debugging with later on. As you can see, the program without debugging symbols is 3140 bytes, while the program with them is 6374 bytes. The program more than doubles in size! Two more things can be done for debugging. The first is adding  to the system's CFLAGS and CXXFLAGS. This flag adds more debugging information than is generally included. We'll see what that means later on. This is how might look with the newly added flags.

You may also want to consider using  and   flags as well. prints compiler warnings, and  produces debugging information in the operating system's native format which also works with gdb. See GCC Debugging Options for details.

Lastly, add debug to the specific package's USE flags. This can be done with the file:

Then we re-emerge the package with the modifications we've done so far as shown below.

Now that debug symbols are set it is time to begin debugging the program.

If you need a little more help while debugging, such as being able to see the code within GDB TUI (GDB Text User Interface), install the package and include. You also need to specify the source code folder:

Although not really needed for meaningful backtraces, this significantly helps when actively coding.

Running the program with GDB
Let's say we have a program here called "bad_code". Some person claims that the program crashes and provides an example. You go ahead and test it out:

It seems this person was right. Since the program is obviously broken, there is now a bug at hand. Now, it is time to use to help solve this matter. First we run with the   option, then give it the full program with arguments like shown:

You should see a prompt that says "(gdb)" and waits for input. First, run the program. Type at the command to receive a notice:

Here we see the program starting, as well as a notification of SIGSEGV, or Segmentation Fault. This is GDB telling us that the program has crashed. It also gives the last run function it could trace when the program crashes. However, this is not too useful, as there could be multiple strcpy's in the program, making it hard for developers to find which one is causing the issue. In order to help them out, we do what's called a backtrace. A backtrace runs backwards through all the functions that occurred upon program execution, to the function at fault. Functions that return (without causing a crash) will not show up on the backtrace. To get a backtrace at the (gdb) prompt type in. Something similar to the following message should be returned:

You can notice the trace pattern clearly. is called first, followed by, and somewhere in   lies the   at fault. Things such as this help developers narrow down problems. There are a few exceptions to the output. First off is forgetting to enable debug symbols with. With debug symbols stripped, the output looks something like this:

This backtrace contains a large number of  (question) marks. This is because without debug symbols, does not know how the program was run. Hence, it is crucial that debug symbols are not stripped. Remember a while ago we mentioned the  flag was mentioned? Let's see what the output looks like with that flag enabled:

Here we see that a lot more information is available for developers. Not only is function information displayed, but even the exact line numbers of the source files. This method is the most preferred if you can spare the extra space. Here's how much the file size varies between debug, strip, and -ggdb enabled programs.

As you can see,  adds about 13178 more bytes to the file size over the one with debugging symbols. However, as shown above, this increase in file size can be worth it if presenting debug information to developers. The backtrace can be saved to a file by copying and pasting from the terminal (if it's a non-x based terminal, you can use gpm. To keep this article simple, it is recommended users read up on GPM documentation to understand how to copy and paste with it). Now that we're done with, we can quit.

This ends the walk-through of. Using, we hope that you will be able to use it to create better bug reports. However, there are other types of errors that can cause a program to fail during run time. One of the other ways is through improper file access. We can find those using a nifty little tool called.