Archive for Januar, 2009

Almost everybody of us already wrote at least a small C or C++ program and struggled with different problems along the way of completion of the program.

Since C or C++ is mostly written in plain text editors fancy features like typically available from Java (debugging, IDE support etc) are not available. Of course one can argue there is Eclipse CDT or NetBeans or even Windows, but all these programs have a huge drawback when it comes to custom maintained makefiles etc. But back to the topic. What happens if we see that errors occur during program execution. Typically the easiest solution is to write simple debug output statements issuing text that helps to understand what is wrong. Of course again writing tests would make everything easier, but again I must contradict (at least in the beginning) – writing tests in C or C++ is pain in the … and for exploring features or the languages it’s simply not useful.

The more complex the program structure get, the more complex it becomes to create useful debug statements that help to understand what is going on and very easily you come to a point where you say:

Damn, I missed to add this and this statement here and there and now I have to compile everything again…

This should not be. Even for people that are typically used of graphical development environments it is not to hard to understand how GDB works and how to became in a short time capable of mastering the most important tasks.

The big question is: Where to start? Let’s assume we have a program that crashes and now we want to debug it. I prepared a very easy program that crashes soon after starting the program.

#include <stdlib .h>
#include <stdio .h>

void test(int a)
{
	int b = 10;

	float c = b + 100;

	printf("%f", c);
}

int main(int argc, char** argv)
{
	int a = 10;
	float f = 10.2;

	test(10);

	int *e = NULL;

	int b = *(e + 10);

	return 0;
}

This program as is will fail because of a simple reason: there is an assignment of a variable with not assigned value to another variable. The question is now how to start debugging if the program once compile (don’t forget the -g flag) and dumped with a segmentation fault etc.

The first step is to start GDB using the simple gdb command from your favorite terminal. Once it is open it will look like the following:

GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".
(gdb)

This screen tells you that GDB is ready and waiting for your input. Right from here you can start build, run, debug etc using the interactive GDB console. The biggest problem I see right here is, that there is no nice screen that tells you how to start debugging and so you are left alone a little bit. To overcome these initial problems I will explain you the most important commands for GDB and show you how to use them later on in a small screen cast.

So here is the list, sorted from most important to least important:

• file – specifies which executable to load. Once specified this will be used through the rest of the session.
• run arg1…argn – this will run the given program and break if it reaches a breakpoint or an abnormal program state
• break < em >location – set a breakpoint at the given location. This can be a symbol, a filename or an address.
• print symbol – prints the value of the symbol. Can be used as a plain debug output statement
• step | next | continue – they do what they look like. Step steps into the next available source position, while next proceeds to the next position in the same function and continue continues until the next program stop via a breakpoint, exception or program termination.
• bt – prints a backtrace for the current position. This can be used to examine the current position in the stack
• frame number – used to navigate to the given frame and show frame info.
• list {+ | – | location} – display the corresponding source code for the given position or location. + and – navigate up and down the source file.
• info scope function name – displays all local variables of the given scope. This can be use to check which variables are defined.
• whatis symbol – prints the type of the symbol

Using these commands you have a suitable knowledge about how to work with GDB. Now using a screencast I will show you how to use these shortcuts in action.