 | |
 | |
| Developer(s) | GNU Project |
|---|---|
| Initial release | 1986; 39 years ago (1986) |
| Stable release | 16.2[1]  / 1 February 2025 |
| Repository | |
| Written in | C,C++,Python |
| Operating system | Unix-like,Windows |
| Type | Debugger |
| License | GPLv3 |
| Website | www |
TheGNU Debugger (GDB) is aportabledebugger that runs on manyUnix-like systems and works for manyprogramming languages, includingAda,Assembly,C,C++,D,Fortran,Haskell,Go,Objective-C,OpenCL C,Modula-2,Pascal,Rust,[2] and partially others.[3]
GDB was first written byRichard Stallman in 1986 as part of hisGNU system, after hisGNU Emacs was "reasonably stable".[4] GDB isfree software released under theGNU General Public License (GPL). It was modeled after theDBX debugger, which came withBerkeley Unix distributions.[4]
From 1990 to 1993 it was maintained byJohn Gilmore.[5] Now it is maintained by the GDB Steering Committee which is appointed by theFree Software Foundation.[6]
GDB offers extensive facilities for tracing and altering the execution ofcomputer programs. The user can monitor and modify the values of programs' internalvariables, and even callfunctions independently of the program's normal behavior.
GDB target processors (as of 2003)[needs update] include:Alpha,ARM,AVR,H8/300, AlteraNios/Nios II,System/370,System 390,x86 and its 64-bit extensionx86-64,IA-64 "Itanium",Motorola 68000,MIPS,PA-RISC,PowerPC,RISC-V,SuperH,SPARC, andVAX. Lesser-known target processors supported in the standard release have includedA29K,ARC,ETRAX CRIS,D10V,D30V,FR-30,FR-V,Intel i960,68HC11,Motorola 88000,MCORE,MN10200,MN10300,NS32K,Stormy16, andZ8000. (Newer releases will likely not support some of these.) GDB has compiled-insimulators for even lesser-known target processors such likeM32R orV850.[7]
GDB is still actively being developed. As of version 7.0 new features include support forPython scripting[8] and as of version 7.8GNU Guile scripting as well.[9] Since version 7.0, support for "reversible debugging" — allowing a debugging session to step backward, much like rewinding a crashed program to see what happened — is available.[10]
GDB offers a "remote" mode often used when debugging embedded systems. Remote operation is when GDB runs on one machine and the program being debugged runs on another. GDB can communicate to the remote "stub" that understands GDB protocol through a serial device or TCP/IP.[11] A stub program can be created by linking to the appropriate stub files provided with GDB, which implement the target side of the communication protocol.[12] Alternatively,gdbserver can be used to remotely debug the program without needing to change it in any way.
The same mode is also used byKGDB for debugging a runningLinux kernel on the source level with gdb. With KGDB, kernel developers can debug a kernel in much the same way as they debug application programs. It makes it possible to place breakpoints in kernel code, step through the code, and observe variables. On architectures where hardware debugging registers are available, watchpoints can be set which trigger breakpoints when specified memory addresses are executed or accessed. KGDB requires an additional machine which is connected to the machine to be debugged using aserial cable orEthernet. OnFreeBSD, it is also possible to debug usingFireWiredirect memory access (DMA).[13]
The debugger does not contain its owngraphical user interface, and defaults to acommand-line interface, although it does contain atext user interface. Several front-ends have been built for it, such asUltraGDB,Xxgdb,Data Display Debugger (DDD), Nemiver,KDbg, theXcode debugger, GDBtk/Insight, Gede[1], Seer[2], and HP Wildebeest Debugger GUI (WDB GUI).IDEs such asCodelite,Code::Blocks,Dev-C++,Geany, GNAT Programming Studio (GPS),KDevelop,Qt Creator,Lazarus,MonoDevelop,Eclipse,NetBeans, andVisual Studio can interface with GDB.GNU Emacs has a "GUD mode" and tools forVim exist (e.g. clewn). These offer facilities similar to debuggers found in IDEs.
Some other debugging tools have been designed to work with GDB, such asmemory leak detectors.
GDB uses a system call namedptrace (the name is an abbreviation of "process trace") to observe and control the execution of another process, and examine and change the process' memory and registers.
| Common gdb commands | Corresponding ptrace calls |
|---|---|
(gdb)start | PTRACE_TRACEME – makes parent a tracer (called by a tracee) |
(gdb)attach PID | PTRACE_ATTACH – attach to a running process |
(gdb)stop | kill(child_pid, SIGSTOP) (orPTRACE_INTERRUPT) |
(gdb)continue | PTRACE_CONT |
(gdb)info registers | PTRACE_GET(FP)REGS(ET) andPTRACE_SET(FP)REGS(ET) |
(gdb)x | PTRACE_PEEKTEXT andPTRACE_POKETEXT |
A breakpoint is implemented by replacing an instruction at a given memory address with another special instruction. Executing breakpoint instruction causes SIGTRAP.
$gdbprogram | Debug "program" (from the shell) |
|---|---|
(gdb)run -v | Run the loaded program with the parameters |
(gdb)bt | Backtrace (in case the program crashed) |
(gdb)info registers | Dump all registers |
(gdb)disas $pc-32, $pc+32 | Disassemble |
Consider the following source-code written inC:
#include<stdio.h>#include<stdlib.h>#include<string.h>size_tfoo_len(constchar*s){returnstrlen(s);}intmain(intargc,char*argv[]){constchar*a=NULL;printf("size of a = %lu\n",foo_len(a));exit(0);}
Using theGCC compiler onLinux, the code above must be compiled using the-g flag in order to include appropriate debug information on the binary generated, thus making it possible to inspect it using GDB. Assuming that the file containing the code above is namedexample.c, the command for thecompilation could be:
$gccexample.c-Og-g-oexampleAnd the binary can now be run:
$./exampleSegmentation fault
Since the example code, when executed, generates asegmentation fault, GDB can be used to inspect the problem.
$gdb./exampleGNU gdb (GDB) Fedora (7.3.50.20110722-13.fc16)Copyright (C) 2011 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <https://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:<https://www.gnu.org/software/gdb/bugs/>...Reading symbols from /path/example...done.(gdb)runStarting program: /path/exampleProgram received signal SIGSEGV, Segmentation fault.0x0000000000400527 in foo_len (s=0x0) at example.c:77 return strlen (s);(gdb)print s$1=0x0
The problem is present in line 7, and occurs when calling the functionstrlen (because its argument,s, isNULL).Depending on the implementation of strlen (inline or not), the output can be different, e.g.:
GNU gdb (GDB) 7.3.1Copyright (C) 2011 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <https://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 "i686-pc-linux-gnu".For bug reporting instructions, please see:<https://www.gnu.org/software/gdb/bugs/>...Reading symbols from /tmp/gdb/example...done.(gdb)runStarting program: /tmp/gdb/exampleProgram received signal SIGSEGV, Segmentation fault.0xb7ee94f3 in strlen () from /lib/i686/cmov/libc.so.6(gdb)bt#00xb7ee94f3instrlen()from/lib/i686/cmov/libc.so.6#10x08048435infoo_len(s=0x0)atexample.c:7#20x0804845ainmain(argc=<optimizedout>,argv=<optimizedout>)atexample.c:14
To fix the problem, the variablea (in the functionmain) must contain a valid string. Here is a fixed version of the code:
#include<stdio.h>#include<stdlib.h>#include<string.h>size_tfoo_len(constchar*s){returnstrlen(s);}intmain(intargc,char*argv[]){constchar*a="This is a test string";printf("size of a = %lu\n",foo_len(a));exit(0);}
Recompiling and running the executable again inside GDB now gives a correct result:
$gdb./exampleGNU gdb (GDB) Fedora (7.3.50.20110722-13.fc16)Copyright (C) 2011 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <https://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:<https://www.gnu.org/software/gdb/bugs/>...Reading symbols from /path/example...done.(gdb)runStarting program: /path/examplesize of a = 21[Inferior 1 (process 14290) exited normally]
GDB prints the output ofprintf in the screen, and then informs the user that the program exited normally.
Then after GNU Emacs was reasonably stable, which took all in all about a year and a half, I started getting back to other parts of the system. I developed a debugger which I called GDB which is a symbolic debugger for C code, which recently entered distribution. Now this debugger is to a large extent in the spirit of DBX, which is a debugger that comes with Berkeley Unix.
| Authority control databases: National |
|---|
