Development/GDB
|
The main documentation is available via |
| Description | Content |
|---|---|
| module load | devel/gdb |
| License | GPL |
| Citing | n/a |
| Links | Homepage | Documentation | Wiki | Mailinglists |
| Graphical Interface | No |
| Included modules | icc | icpc | ifort | idb |
Description
The GNU Debugger (GDB) is a standard debugger for serial programs although it can be used for parallel and even distributed programs with few processes too. In the past Intel supported their own idb debugger, however this has been deprecated in favor of their own port called gdb-ia.
Basic commands
The code you want to debug should be compiled with the -g option. If the optimization flag is not set, GCC will still do some basic optimization, like dead-code elimination or reorder instruction execution obfuscating the order when debugging. Therefore, it is recommended to turn off optimization explicitly with the -O0 parameter for debugging. To start a debug session for a program execute GDB with the program path as parameter:
$ gdb ./example
Inside GDB is a prompt where you can enter commands. Important commands are listed below.
| Command | Description |
|---|---|
| help cmd | Show help for command cmd. |
| break func | Set a breakpoint at function func. |
| run | Start program. |
| next | Go to next program line. Do not enter functions. |
| step | Go to next program line. Enter functions. |
| list | Show the surrounding source code of the currently processed line. |
| print expr | Print the value of the expression expr. |
| display expr | Display the value of the expression expr every time the program stops. |
| watch expr | Stop when value of the expression expr changes. |
| continue | Continue execution until a breakpoint or a watchpoint appears. |
| backtrace | Print a list of functions that are currently active. |
| quit | Exit GDB. |
Branch record tracing
Starting with GBD-10.1, the debugger has been installed with Intel Processor Trace libipt, allowing recording and replaying of process state. This allows disassembling previously executed instructions, checking for previously called functions and branch tracing.
Honestly, Segmentation Violations are better caught using Valgrind. However in this case, valgrind would not have helped: this loops overwrites v an array of 2 ints on the stack and the return address leading to the execution of IP 0x07.
More information is available in gdb's feature documentation
Core dumps
When the program crashes, a log file (called core dump) can be created which contains the state of the program when it crashed. This is turned off by default because these core dumps can get quite large. If you want to turn it on you have to change your ulimits, for example:
$ ulimit -c unlimited
Every time your program crashes a new file called core.xxx (where xxx is a number) will be created in the directory from which you started the executable. You can call gdb to examine your core dump using the following command (assuming your program is called ex):
$ gdb ./ex core.xxx
Now you can print a backtrace to check in which function the error happened and what values the parameters had. Additionally you can examine the values of your variables to reproduce the error.
Multithreaded debugging
GDB can also be useful for multithreaded applications for example when OpenMP was used. By going through each thread separately you can better see what is really going on and you can check the computation step by step. The following commands are useful for multithreaded debugging: