1. 项目概述为什么你需要这份GDB命令手册如果你写过C/C或者搞过嵌入式、逆向那你肯定对“段错误”Segmentation fault或者程序跑着跑着就“卡死”不陌生。这时候光靠printf打印日志效率低得像大海捞针。GDBGNU Debugger就是那个能把你从崩溃边缘拉回来的“外科手术刀”它能让你像看电影一样一帧一帧地观察程序内部的状态变化。但GDB的命令行界面对新手来说确实不太友好。网上资料要么太零散要么就是罗列命令却不讲清楚“为什么”和“什么时候用”。我自己从学生时代用GDB调单片机程序到后来在服务器上追查内存泄漏踩过的坑不计其数。这份总结就是把我这些年高频使用、真正能解决问题的GDB命令结合具体的调试场景和示例操作给你掰开揉碎了讲清楚。目标很简单让你手边有一份能“即查即用”的实战指南下次程序再“作妖”时你能快速定位问题而不是对着黑屏终端发呆。2. GDB调试核心思路与准备工作调试不是漫无目的地试错而是一个有明确目标的侦查过程。在使用任何命令之前你得先想清楚我到底要看什么是程序崩溃时的现场是某个变量为何变成了奇怪的值还是函数调用的路径不对2.1 调试的“正确姿势”编译与启动很多新手第一步就错了。直接用发行版的二进制文件去调试会发现连变量名都看不到。这是因为默认的编译选项尤其是-O2优化会改变代码结构删除调试信息。关键一步带调试信息编译在你用gcc或g编译时必须加上-g选项。这个选项会在可执行文件中嵌入源代码位置、变量类型、函数名等符号信息这是GDB能进行源码级调试的基础。# 正确编译示例 gcc -g -o my_program my_program.c # 对于C同样适用 g -g -o my_app main.cpp utils.cpp注意-g和优化选项如-O2可以同时使用但高等级优化可能会重组代码导致调试时行号对不上或变量被优化掉。在深度调试阶段建议使用-g -O0来完全关闭优化确保调试体验最直观。启动GDB的几种方式直接调试程序gdb ./my_program调试正在运行的进程gdb -p pid。这在调试服务器后台进程时极其有用可以附着attach上去而不中断服务当然断点会中断。分析核心转储文件Core Dumpgdb ./my_program core。当程序崩溃产生core文件时这是事后分析的唯一途径。需要系统允许生成core文件ulimit -c unlimited。启动后GDB会进入自己的命令行环境(gdb)。这时程序还没开始运行。2.2 基础命令控制程序的生与死在设置断点前你得知道如何让程序跑起来、停下来、继续跑。run(或r): 开始运行程序。可以带参数例如run arg1 arg2就像在shell中执行./my_program arg1 arg2一样。start: 一个更温和的启动方式。它会在main函数的第一行代码处自动设置一个临时断点然后执行run。这样程序一启动就暂停方便你从入口开始单步跟踪。continue(或c): 从当前断点处继续运行直到遇到下一个断点、信号或程序结束。next(或n):单步执行。执行下一行源代码。关键区别如果下一行是一个函数调用next会把这个函数作为一个整体执行完然后停在函数调用后的下一行。你“跳过”了函数内部细节。step(或s):单步进入。执行下一行源代码。关键区别如果下一行是函数调用step会进入该函数内部停在函数的第一行代码。你想深入函数内部排查时就用它。finish: 执行完当前函数并返回到它的调用者处暂停。当你误入一个不关心的函数比如step过头了想快速出来时非常方便。until(或u): 一个实用的命令用于跳出循环。当你停在循环体内又不想一次次按next时输入untilGDB会一直运行直到循环结束或遇到其他断点。kill: 终止当前正在调试的程序但保持GDB会话不退出。之后你可以用run重新启动它。实操心得next和step是最常用的两个命令一定要分清。我习惯用n快速掠过确认无误的代码用s深入可能有问题的函数。当你面对一个很深的调用栈时灵活组合step,next,finish能让你在代码中快速穿梭。3. 断点管理在关键位置设下“路障”断点是调试的基石。你的侦查能力很大程度上取决于你设断点的水平。3.1 设置断点的多种姿势break(或b): 最常用的命令。break main: 在main函数入口处设断点。break 20: 在当前源文件的第20行设断点。break filename.c:30: 在指定文件filename.c的第30行设断点。break function_name: 在名为function_name的函数入口处设断点。条件断点Conditional Breakpoint这是高级用法能极大提升效率。只有当条件满足时断点才会触发。(gdb) break 45 if i 100这会在第45行设置一个断点但只有当变量i的值等于100时程序才会在此暂停。在调试循环中寻找特定迭代的问题时这能帮你省去无数次的continue。临时断点Temporary Breakpointtbreak。这个断点只会生效一次触发后自动删除。适用于你只想在某个位置停一次的场景。观察点Watchpointwatch。这不是行断点而是数据断点。当某个表达式的值发生变化时程序暂停。watch variable_name: 当variable_name被写入值改变时暂停。rwatch variable_name: 当variable_name被读取时暂停。awatch variable_name: 当variable_name被读取或写入时暂停。注意事项观察点是通过硬件特性实现的资源有限。如果设置太多或观察复杂表达式可能会显著降低程序运行速度甚至在某些平台上不支持。3.2 查看与管理断点列表设了断点你得知道它们在哪。info breakpoints(或i b): 列出所有断点、观察点的信息。你会看到每个断点的编号Num、类型Type、是否启用Enb、地址Address和位置What。disable breakpoint_num: 禁用编号为breakpoint_num的断点。它还在列表里但不会触发。enable breakpoint_num: 重新启用被禁用的断点。delete breakpoint_num: 删除指定编号的断点。delete不带参数会询问是否删除所有断点。clear: 清除在当前执行位置当前帧的断点。例如你停在第20行clear就会删除设置在第20行的断点。也可以用clear function_name来清除函数入口断点。实操示例假设你在调试一个图像处理函数process_image它处理到第1024个像素时出错。你可以在函数入口设断点b process_image。运行程序停在入口。你想直接跳到处理第1024个像素的那次循环迭代。假设循环变量是pixel_index你可以设置条件断点b 内部循环行号 if pixel_index 1024。然后continue程序会飞速运行直到pixel_index为1024时才停下让你直接观察错误现场。4. 洞察程序内部查看变量、内存与调用栈程序停下来了现在你需要像法医一样检查现场。4.1 查看变量与表达式print(或p): 打印变量或表达式的值。这是使用频率最高的命令之一。p variable: 打印变量的当前值。p array[10]: 打印数组元素。p *pointer: 解引用指针打印指向的内容。p variable5: 不仅打印还会修改变量的值为5这在测试不同输入场景时非常有用。p /x variable: 以十六进制格式打印变量。/x是格式标识其他常用格式还有/d: 十进制默认/u: 无符号十进制/o: 八进制/t: 二进制/c: 字符/f: 浮点数/s: 字符串用于打印char*display: 设置自动显示表达式。每次程序暂停比如执行next或遇到断点GDB都会自动打印出你display的表达式。适合监控关键变量的变化。display variable_nameinfo display: 查看所有自动显示项。undisplay display_num: 删除编号为display_num的自动显示项。whatis: 查看变量的类型。例如whatis ptr会告诉你ptr是int *还是char **。ptype: 比whatis更详细打印类型的完整定义。对于结构体struct或类class特别有用。4.2 检查内存内容当怀疑指针越界、缓冲区溢出或内存被意外篡改时需要直接查看原始内存。x(examine): 检查内存命令。语法是x/[数量][格式][单位] 内存地址。格式和print的格式类似如x(十六进制)、d(十进制)、s(字符串)、i(指令)。单位b(字节)、h(双字节/半字)、w(四字节/字)、g(八字节/巨字)。示例x/10xw array: 以十六进制(x)格式显示从array地址开始的10个四字节(w)字。x/s pointer: 将pointer指向的内存当作C风格字符串(s)显示直到遇到\0。x/20i $pc: 显示当前程序计数器($pc)位置开始的20条汇编指令(i)。这在分析崩溃的汇编层面时至关重要。实操心得x命令的参数顺序容易记混。我的窍门是记住“看几个怎么看看多大”。比如x/4xg 0x7fffffffdc10就是“看4个用十六进制看每个看8字节巨字从地址0x7fffffffdc10开始”。4.3 回溯调用栈Backtrace程序崩溃或停在断点时你往往需要知道“我是怎么走到这里的”调用栈Call Stack就是函数调用的历史记录。backtrace(或bt): 打印当前的调用栈。最下面的是最早调用的函数通常是main最上面的是当前正在执行的函数。backtrace full(或bt full): 不仅打印栈帧还打印每个栈帧中所有局部变量的值。信息量巨大是分析复杂问题的利器。frame(或f): 切换栈帧。bt输出的每一行前面都有一个编号如#0,#1。使用frame 2可以切换到第2号栈帧即调用当前函数的那个函数。up/down: 在栈帧间向上调用者或向下被调用者移动。切换后你就可以用print查看那个帧的局部变量了。示例操作程序在deep_function里段错误。用bt查看发现调用链是main - func_a - func_b - deep_function。你怀疑是func_b传错了参数。用frame 2切换到func_b对应的栈帧。现在你可以用p parameter_in_func_b来检查当时传入的参数值是否正确。5. 高级调试与问题排查实战掌握了基础我们来看一些更复杂但极其常见的调试场景。5.1 调试多线程程序现代程序多是多线程的GDB也提供了相应的支持。info threads: 列出所有线程显示每个线程的ID和当前正在执行的函数或地址。thread thread_id: 切换到指定ID的线程进行调试。切换后你设置的断点、查看的变量都是针对这个线程的上下文。thread apply [thread_id] command: 对所有或指定线程执行同一个GDB命令。例如thread apply all bt可以一次性获取所有线程的调用栈这在诊断死锁时非常有用看看各个线程都在等哪把锁。注意事项默认情况下当你用next或step单步调试一个线程时其他线程是自由运行的。这可能导致状态难以重现。你可以用set scheduler-locking on命令锁定调度器确保只有当前调试的线程会执行其他线程暂停。排查完记得set scheduler-locking off打开。5.2 调试已崩溃的程序Core Dump分析程序崩溃后生成了一个core文件这是程序死亡瞬间的“内存快照”。确保能生成core文件在Linux下默认可能不生成或core文件大小限制为0。在运行程序前在终端执行ulimit -c unlimited。加载core文件gdb ./my_program core查看死亡现场GDB加载后会直接停在程序崩溃如收到SIGSEGV信号的那条指令上。第一件事就是bt查看崩溃时的调用栈。检查相关变量和内存根据bt的线索切换到相应的栈帧用print和x检查可疑的指针、数组索引、内存内容。常见问题包括空指针解引用、访问已释放内存、栈溢出、缓冲区溢出等。实操心得分析core文件时务必使用带-g编译选项生成的、与崩溃时完全一致的可执行文件。如果可执行文件后来被重新编译过地址对不上调试信息就全乱了。5.3 自定义命令与脚本化对于重复性的调试操作GDB支持脚本化。define: 可以自定义命令。(gdb) define mywatch watch my_global_var continue end之后输入mywatchGDB就会自动设置观察点并继续运行。source: 执行一个包含GDB命令的脚本文件。你可以把常用的断点设置、显示命令写在一个.gdbinit文件里启动GDB时自动加载或者用source my_script.gdb手动加载。.gdbinit文件在你的家目录~/.gdbinit或当前调试目录下放置此文件GDB启动时会自动执行其中的命令。可以在这里设置喜欢的打印格式、定义别名等。5.4 汇编级调试有时候尤其是优化过的代码或者没有调试信息的库你不得不面对汇编。layout asm: 切换到汇编代码视图如果GDB编译时支持TUI。disassemble(或disas): 反汇编当前函数或指定地址范围的代码。stepi(或si) /nexti(或ni): 类似于step和next但是以单条汇编指令为单位执行。info registers(或i r): 显示所有CPU寄存器的当前值。对于分析低级错误如错误的系统调用参数必不可少。6. 常见问题排查与实用技巧速查这里汇总了调试中最常遇到的“坑”和应对技巧。6.1 GDB不显示源代码或提示“No symbol table”问题启动GDB后list命令没反应断点设不了行号。原因可执行文件没有包含调试信息编译时没加-g。解决重新用gcc -g ...编译。如果调试的是第三方库需要安装对应的-dbgsym或-debuginfo包取决于发行版。6.2 打印指针或数组内容不直观问题p pointer只打印一个地址p array打印一长串看不出规律。技巧对于int*或数组用p *pointer10可以打印从pointer开始的10个元素。是打印数组的利器。对于C STL容器如std::vector直接p vec可能很乱。可以尝试p vec._M_impl._M_start查看底层指针或者使用GDB的Python脚本支持如果编译时支持输入p vec可能会自动调用漂亮的打印机pretty-printer。6.3 程序在GDB中能运行直接运行就崩溃问题典型的“海森堡bug”观察者效应。有时是因为GDB环境改变了程序的行为如信号处理、内存布局的微小差异。排查在GDB外运行让程序崩溃生成core文件。用GDB分析core文件这是最真实的状态。检查是否是多线程时序问题。GDB默认的调度可能掩盖了竞争条件。尝试在GDB中用set scheduler-locking off让线程自由竞争看是否能复现。6.4 断点打不上或位置不对问题break function_name提示“Function not defined”或者断点停的位置和源码行对不上。原因函数名拼写错误或者因为C名字修饰name mangling导致符号不对。可以用info functions查看所有函数符号。代码被编译器优化了如内联函数。优化后的代码行号信息可能不准确。解决对于C可以使用break Namespace::Class::method(int)这种包含完整签名的名称或者用Tab键补全。尝试在函数入口的汇编地址设断点先disas function_name找到入口地址然后break *0x地址。6.5 实用命令速查表命令简写功能描述常用场景run [args]r运行程序开始调试break [location]b设置断点在函数、行号处暂停break ... if cond设置条件断点循环中特定条件触发continuec继续运行从一个断点到下一个nextn单步执行不进入函数快速掠过已知函数steps单步执行进入函数深入未知函数内部finishfin执行完当前函数从当前函数跳出print exprp打印表达式值查看变量状态display exprdisp自动显示表达式持续监控关键变量backtracebt打印调用栈分析崩溃路径frame numf切换栈帧查看调用者上下文info breakpointsi b查看断点信息管理断点列表watch expr设置观察点值变暂停追踪变量何时被修改x/[nfu] addr检查内存分析指针、缓冲区内容thread infoi th查看线程信息多线程调试set varvalue设置变量值动态改变程序状态测试最后再分享一个我自己的小习惯在复杂的调试会话开始前我会先用gdb -q ./program启动。-q参数表示“安静模式”它会抑制GDB启动时的版权信息等一堆输出让终端更干净专注在你要执行的命令上。调试本身已经够烧脑了让界面清爽一点心情也会好一些。