gdb debugger

GDB stands for GNU Project Debugger. GDB（GNU Debugger）是UNIX及UNIX-like下的強大調試工具，可以調試ada, c, c++, asm, minimal, d, fortran, objective-c, go, java,pascal等語言。本文以C程序為例如，介紹GDB啟動調試的多種方式。

1. Compile your code with debugging option

Launch gdb

In general, it is

gdb ./wrf.exe

but most of time, it is by mpirun,

mpirun -n 1 gdb ./wrf.exe

Sample output,

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-110.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /xxx/WRFV4.4_debug/main/wrf.exe...done.
(gdb)

commands

Here are few useful commands to get started with gdb for the above example:

run or r –> executes the program from start to end.
break or b –> sets breakpoint on a particular line.
disable -> disable a breakpoint.
enable –> enable a disabled breakpoint.
delete -> delete a breakpoint by index 1,2,3,...
next or n -> executes next line of code, but don’t dive into functions.
step –> go to next instruction, diving into the function.
list or l –> displays the code.
print or p –> used to display the stored value.
quit or q –> exits out of gdb.
clear –> to clear all breakpoints.
continue –> continue normal execution.
reverse-next -> Run the program backward
reverse-step -> Run the program backward
reverse-continue -> Run the program backward

movement

up (n)
down (n)
print or p

Single step execution -next

The next command (can be abbreviated as n) is used to continue to execute the next statement after the program is stopped, assuming that debugging has been started, and stop at line 10, if you want to continue execution, use n to execute the next statement, if later Keeping up with the number num, it means that the instruction is executed num times, and the effect of continuing to execute n lines is achieved.

(gdb) b 10
Breakpoint 1 at 0x405b26: file wrf.f90, line 10.
(gdb) run
Starting program: /xxx/./wrf.exe 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, wrf () at wrf.f90:22
22        CALL wrf_init
Missing separate debuginfos, use: debuginfo-install ...
(gdb) n
 starting wrf task            0  of            1
25        CALL wrf_dfi

Step into -step

For the above situation, if we want to track the internal situation of the function, we can use the step command (which can be abbreviated as s), which can single-step trace to the inside of the function, but only if the function has debugging information and source code information.

core document

When a program core dumps, a core file may be generated, which can help us identify location problems for a large enough program. But it was proposed before that the system does not limit the generation of core files. You can use the command limit - c to view:

$ ulimit -c
0
$ ulimit -c unlimited  # Indicates that there is no limit to the core file size

Or add at the end of ~/.bashrc: ulimit -c unlimited

check breakpoints

$ info breakpoints

set breakpoints

$ b 10
$ b main.c:10 # Important
$ b Function

Generate breakpoints based on expression value changes

Sometimes we need to observe a certain value or expression to know when it has changed. At this time, we can use the watch command. For example:

$ watch a

At this time, let the program continue to run. If the value of a changes, the relevant content will be printed, such as：

Hardware watchpoint 2: a
Old value = 12
New value = 11

But here to pay attention is that the program must be running, otherwise it will appear: > No symbol "a" in current context. Because the program is not running, the current context has no relevant variable information.

TUI(Text User Interface)

The GDB Text User Interface, TUI in short, is a terminal interface which uses the curses library to show the source file, the assembly output, the program registers and GDB commands in separate text windows.

$ gdb main -tui

Sounds like what you're looking for is the callstack/backtrace. For that, just use the > $ (gdb) backtrace/bt or where

command.

frame

1. According to the stack frame number or stack frame address, select the stack frame to be viewed. The syntax format is as follows: > (gdb) frame spec
2. With the help of the following command, we can view the information stored in the current stack frame: > (gdb) info frame

backtrace/bt

backtrace

The command is used to print the information of all stack frames in the current debugging environment

Step out of current function with GDB

You can use the finish command. > finish: Continue running until just after function in the selected stack frame returns. Print the returned value (if any). This command can be abbreviated as fin.

Reserse

reverse-next -> Run the program backward
reverse-step -> Run the program backward
reverse-continue -> Run the program backward

Example: WRF

$ source wrf_env.sh

(gdb) b solve_em.F:xxx                       # try to stop before CALL first_rk_step_part1(...)
(gdb) b module_first_rk_step_part1.f90:387   # try to stop before CALL surface_driver(...)
(gdb) b module_surface_driver.f90:2683       # try to stop before CALL lsm(...) 
(gdb) b module_sf_noahdrv.f90:1234           # try to stop before Call urban(...) for WRF
(gdb) b module_sf_noahdrv.F:xxxx             # try to stop before Call urban(...) for MPAS
(gdb) run
...
(gdb) n/s/p/f/bt

Inferior 1 (process ) exited normally

That is not an error, from gdb's point of view. Your program just finished gracefully, with a return value of 0, and gdb informs you of that.

What does no stack mean in gdb?

Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-?

1. Install debuginfos
2. $ debuginfo-install glibc