我们在开发软件时，免不了引入一些Bug，如何快速定位并解决这些bug 呢？工程师调试跟踪解决这些bug 的过程就像是医生给病人体检治病，医生需要借助各种医疗设备检测病人的各项指标，才能诊断病情分析病因并给出治疗方案。工程师解决这些bug，也需要借助各种调试跟踪技术，通过查看当前的执行指令、内存数据、运行日志等信息，分析出产生bug 的可能原因，再给出解决方案。

这些调试跟踪技术，可以帮我们更清晰的了解代码的执行状态，快速找到执行结果与期望结果不相符的起点或原因，比如控制逻辑或业务逻辑出现漏洞、中间结果被意外更改或损坏、低效的性能瓶颈等。

我们初学程序设计时，C/C++/Java 这些静态类型语言都需要先经过编译、链接、执行过程，linux 系统常用的编译链接工具是GCC。程序设计免不了出现一些非预期的Bug，要解决这些bug 首先需要我们获得当前代码足够的执行信息，GNU 也提供了GDB 调试工具，供我们查看代码的执行信息，快速定位产生bug 的代码并解决它。

一般我们在程序开发过程中，代码编辑、编译链接、代码调试这几个工具配合使用，所以很多 IDE(Intergreated Development Environment) 常将这几部分封装在一起，比如windows 平台下的Visual Studio、嵌入式开发常用的Keil MDK 等。这些IDE 工具将常用操作以菜单按钮的形式提供，让我们专注于程序开发过程，对我们隐藏了编译链接和代码调试工具的原理，本文以GDB 为例，简单介绍下代码调试原理。

目前软件开发主要在x86 平台上进行，但我们开发的目标程序有可能在其它平台比如ARM 上运行，为了方便我们在PC 上调试ARM 主机中运行的程序，GDB 根据调试程序和被调试程序是否运行在同一台电脑中，提供了如下两种调试模型：

本地调试：调试程序和被调试程序运行在同一台电脑中。

远程调试：调试程序运行在一台电脑中，被调试程序运行在另一台电脑中。

直接跟用户交互的可视化调试程序常有两种形式：一种是在终端窗口内手动输入调试命令，以字符形式显示调试信息；另一种是在IDE 内点击菜单按钮来代替手动输入调试命令，以图形加字符的形式显示调试信息。前一种形式更方便编写脚本实现自动化调试；后一种形式不需要记忆那么多调试命令，呈现的调试信息更直观、视觉辨识度更高，能提高点调试效率。

远程调试相比本地调试，多了一个GdbServer程序，该程序和目标程序（被调试程序）都运行在目标机（比如一个ARM 主板）中。上图中的红线表示GDB与GdbServer之间通过串口线或者网络进行通讯，用于传输GDB 调试消息的通讯协议可以称为GDB Remote Serial Protocol(GDB RSP)。

GDP RSP 既然是一个通讯协议，自然有标准的报文格式和内容要求，基本的报文格式如下图所示： GDP RSP 报文主要包括四个部分，固定的开始字符(’$’)和结束字符(’#’)，中间的调试消息数据以及最后的校验和，我们使用GDB 调试工具并不需要了解的那么详细，这里也就不展开介绍协议报文了（若想了解更详细信息，可参阅文档：Howto: GDB Remote Serial Protocol）。

不管是本地调试还是远程调试，GDB 调试程序都需要有两个条件：

我们先使用man gdb 命令查看GDB 的简单介绍与用法：

GDB 主要有三种启动方式：

从GDB 与被调试程序间的关系看，GDB 的三种启动方式可以分为两类：一类是由GDB 程序调用执行一个尚未运行的被调试程序program；另一类是由GDB 程序attach 接管一个正在运行的被调试程序program。

前面也谈到，GDB 进程可以控制被调试程序的执行，可以访问被调试程序的任何指令和内存数据。GDB 进程相当于是被调试程序的父进程，GDB 进程对被调试进程program 有绝对的控制权。GDB 是如何调用或者接管一个正在运行的被调试程序呢？

Linux 内核提供了一个用于进程跟踪的系统调用函数ptrace，该函数提供了一个进程（the “tracer”）监察和控制另一个进程（the “tracee”）的方法，它不仅可以监控系统调用，而且还能够检查和改变“tracee” 进程的内存和寄存器里的数据，甚至还可以拦截系统调用。GDB 进程通过系统调用函数ptrace，就可以读写被调试进程program（GDB 进程作为tracer，被调试进程作为tracee）的指令空间、数据空间、堆栈和寄存器的值，接管被调试进程program 的所有信号。这样一来，被调试进程program 的执行就被GDB 进程完全控制了，从而达到调试的目的。

我们使用man ptrace 命令查看ptrace 的简单介绍如下： 我们知道了，GDB 进程借助系统调用函数ptrace 实现对被调试进程的监察和控制，也就好理解GDB 进程是如何调用或者接管被调试进程program 的了。对于尚未运行的被调试程序，启动GDB 调试进程后，该进程会创建一个子进程（linux 系统通过fork 创建子进程）并调用ptrace 函数，ptrace 函数再由第一个参数获知是启动一个尚未运行的进程（传入参数值 PTRACE_TRACEME）还是接管一个正在运行的进程（传入参数值 PTRACE_ATTACH 或 PTRACE_SEIZE）。GDB 进程启动或接管被调试进程test 的过程图示如下（接管正在运行的进程，GDB 向其发送信号SIGSTOP，正在运行的被调试进程就会暂停执行并进入TASK_STOPED状态，等待被调试）：

所以，不论是调试一个新程序，还是调试一个已经处于执行中状态的服务程序，通过ptrace系统调用，最终的结果都是：gdb程序是父进程，被调试程序是子进程，子进程的所有信号都被父进程gdb来接管，并且父进程gdb可查看、修改子进程的内部信息，包括：指令空间、数据空间、堆栈、寄存器等。

如何使用GDB 调试程序呢？GDB 提供了一系列命令，我们可以在启动GDB 进程后通过help 命令查看，GDB 支持的调试命令类别如下： 从help 命令的返回结果可以看出，GDB 主要支持12 类调试命令，其中比较常用的有断点设置breakpoints、数据查询data、文件指定与查看files、运行控制running、堆栈查询stack、状态查看status 等六大类。如果想查看某一类具体支持哪些调试命令，可以使用比如help breakpoints 形式的命令查看详情。GDB 支持的调试命令很多，本文只介绍几个最常用的调试命令。

前面已经谈到，要想使用gdb 调试程序，被调试程序需要包含调试信息，如果使用GCC 工具链编译链接程序，则需要添加-g 参数(也可以是-Og 参数)。使用前面介绍的GDB 启动命令，可以根据启动调试后的提示信息判断被调试程序是否包含调试信息：

启动GDB 调试程序后，一般先设置普通断点、观察断点、捕捉断点等，以便在后续调试过程中，让程序及时暂停在我们关注的地方，查看断点处的数据和状态信息。GDB 常用的断点设置命令如下（可通过help breakpoints 查看支持的断点命令列表，可进一步通过help break 查看某个具体命令的用法）：

下面给出这几个命令的简单示例：

在被调试程序代码中设置断点，实际上就是让被调试程序暂停在我们关注的断点位置，一般断点处也是我们怀疑程序存在bug或性能瓶颈的地方。

当被调试程序停在断点处后，我们需要查看当前调试环境的状态与数据信息，比如变量当前值、调用堆栈信息、当前寄存器值等。GDB 常用的变量或堆栈信息查询命令如下：

下面给出这几个命令的简单示例：

为被调试程序设置了需要特别关注的断点，也有了可以查看甚至修改当前调试环境变量值、堆栈信息、寄存器值等数据的命令，还需要能自由控制被调试程序执行顺序的命令，方便进行单步调试或断点调试。GDB 常用的执行控制命令如下：

下面给出这几个命令的简单示例：

上述GDB 调试命令都可以使用缩写形式，比如使用b 代替break、使用c 代替continue、使用bt 代替backtrace 等，不用每次输入命令全称。

使用GDB 命令来调试程序并没有那么直观，我们对可视化的图像信息更敏感些，因此很多IDE 都提供了可视化调试界面。这里使用比较轻巧的代码编辑器VS Code 搭配GCC 和GDB 工具链，实现可视化调试功能。

一般一个软件工程包含不止一个源文件，多个源文件的编译链接通常靠Makefile 控制。使用VS Code 编辑好工程代码和Makefile 文件后，可以在VS Code 启动配置文件launch.json 中配置GDB 调试器和预启动任务preLaunchTask，在任务配置文件tasks.json 中配置执行Makefile 文件中定义的make default 命令，实现对目标工程的可视化调试。

这里使用博文：VSCode+GCC+Makefile项目管理 中的示例代码，考虑到GNU工具链对Linux 系统支持更好，本文使用Ubuntu 20.04系统构建VS Code 可视化调试工程。

原博文是基于windows 系统编写的Makefile 文件和launch.json、tasks.json 配置文件，这里使用Linux 系统需要修改几个地方：

配置好VS Code 后，进入“Run and Debug” 窗口界面，先设置断点和观察表达式，变量和调用栈帧信息会自动显示在想要区域，设置好断点和观察点后，点击“Start Debugging" 按钮开始执行调试任务，界面如下： VS Code 不仅支持可视化变量、断点、堆栈信息列表显示，还支持执行GDB 命令以获得更多信息。继续执行到函数add 内的断点处，在DEBUG CONSOLE 界面执行命令“-exec info frame” 获得当前栈帧详细信息，图示如下：

GDB 调试模型有本地调试和远程调试两种，前面主要基于本地调试介绍的，我们在使用服务器编译或嵌入式调试等场景，就需要在PC 端调试远程服务器或嵌入式板子上的程序了，如何进行GDB 远程调试呢？

在博文：LwIP开发调试环境搭建 中已经展示了在windows 系统上调试虚拟机qemu-vexpress-a9 内运行的程序，调试界面如下： 这里简单解释下GDB 远程调试的命令交互过程，首先执行脚本qemu-dbg.bat 启动qemu-vexpress-a9 虚拟机，主要命令如下：

qemu-dbg 相比qemu 脚本主要多出来两个参数-S 和-s，这两个参数是什么意思呢？我们通过命令帮助查询如下：

从命令帮助可知，qemu-system-arm -s 参数可以让qemu-vexpress-a9 虚拟机在tcp::1234 端口启动gdbserver 服务，相当于在虚拟机内执行了“arm-none-eabi-gdbserver localhost:1234 rtthread.elf” 命令（虚拟机与宿主机共用IP 即localhost，ARM Cortex-A9 使用的编译器为arm-none-eabi-gcc，选用gdbserver 版本应与编译器架构一致）。

启动qemu-vexpress-a9 虚拟机时，通过-s 参数启动了gdbserver 服务，接下来在宿主机内执行如下命令：