从实践到原理掌握 gdb-ag真人游戏

文章目录

• 基本概念
• • 什么是 gdb？
  • gdb 可以用来做些什么？
  • 调试模型
  • • 本地调试
    • 远程调试
  • 安装 gdb
• 实战
• • 启动调试
  • • 调试未运行的程序
    • • 无参数
      • 有参数
    • 调试运行中的程序
    • • 已生成调试信息
      • 未生成调试信息
    • 调试 core 文件
    • • 配置 core 文件生成
      • 调试 core 文件
  • 常用命令
  • • 断点
    • • breakpoint
      • watchpoint
      • catchpoint
    • 调用栈
    • 输出
    • • 变量信息
      • 字符串
      • 数组
      • 指针
      • 内存地址
      • 局部变量
      • 结构体
    • 函数跳转
    • 多线程、多进程
    • • 多进程
      • 多线程
    • 其他
    • • 图形化
      • 汇编
  • 其他工具
  • • pstack
    • ldd
    • strings、c filt
• 原理
• • 调试原理
  • ptrace
  • 调试运行中程序
  • 断点 break
  • 单步 next
• 参考

什么是 gdb？

gdb

gdb（gnu debugger），是一个由 gnu 开源组织发布的、unix/linux 操作系统下的、基于命令行的、功能强大的程序调试工具；gdb 支持断点、单步执行、打印变量、观察变量、查看寄存器、查看堆栈等调试手段；gdb 支持调试多种编程语言编写的程序，包括 c、c 、go、objective-c、opencl、ada 等。实际场景中，gdb 更常用来调试 c 和 c 程序。

gdb 可以用来做些什么？

一般来说，借助 gdb 调试器可以实现以下几个功能：

1. 程序启动时，可以按照我们自定义的要求运行程序，例如设置参数和环境变量。
2. 可使被调试程序在指定代码处暂停运行，并查看当前程序的运行状态（例如当前变量的值，函数的执行结果等），即支持断点调试。
3. 程序执行过程中，可以改变某个变量的值，还可以改变代码的执行顺序，从而尝试修改程序中出现的逻辑错误。

调试模型

根据 gdb 程序与被调试程序是否运行在同一台机器中，可以把 gdb 的调试模型分为以下两种：

• 本地调试
• 远程调试

本地调试

本地调试指的是调试程序和被调试程序运行在同一台机器中，如下图所示：

本地调试

可视化调试程序只是对 gdb 操作的一层封装，例如 visual studio、clion 等 ide 中的可视化调试。当然我们也可以直接通过 bash 来手动输入调试命令。

远程调试

调试程序运行在一台机器中，被调试程序运行在另一台机器中，如下图所示：

远程调试

gdbserver 的主要工作是负责完成 gdb 与目标程序之间的通信，其采用了 rsp（gdb remote serial protocol） 协议。

安装 gdb

这里以 centos 8 举例，来演示 gdb 的安装。

首先查看当前机器中是否存在 gdb：

gdb -v

如果提示 bash: gdb: command not found，则说明当前机器没有，继续执行下面的步骤，反之则无需安装。

通过 yum 安装 gdb：

sudo yum -y install gdb

如果使用的是官方的 yum 下载源，这里就会报错 error: failed to download metadata for repo 'appstream': cannot prepare internal mirrorlist: no urls in mirrorlist，这主要是因为在 2021 年底官方就停止对 centos 8 提供服务，这时我们就需要将 yum 源切换为国内的：

# 进入yum的repos目录
cd /etc/yum.repos.d/
# 修改所有的centos文件内容
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/centos-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/centos-*
# 更新yum源为阿里镜像
wget -o /etc/yum.repos.d/centos-base.repo https://mirrors.aliyun.com/repo/centos-vault-8.5.2111.repo
yum clean all
yum makecache

这时候重新通过 yum 安装即可。

启动调试

gdb 的使用前提：需要在编译时加上-g 参数，保留调试信息，否则会提示 no debugging symbols found，无法使用 gdb 进行调试。

调试未运行的程序

无参数

使用 gdb 可执行程序名 开启调试，输入 run 命令运行程序：

gdb test1
(gdb) run

有参数

直接在 run 后面跟上参数：

gdb test1
(gdb) run "hello world"

也可以通过 set args 命令指定参数列表：

gdb test1
(gdb) set args "hello world"
(gdb) show args # 查看参数列表
(gdb) run

调试运行中的程序

如果程序已经处于运行中的状态，那我们该如何对其进行调试呢？

已生成调试信息

对于已生成调试信息的，我们只需要找到它的进程 id，再使用 attach 命令绑定进程即可：

# 步骤一：找到进程id
ps -ef|grep 进程名
# 或者
pidof 进程名
# 步骤二：开启gdb调试
gdb
# 步骤三：attach绑定对应的进程id
attach [进程id]
# 或者在启动时直接指定程序名与进程id
gdb [程序名] --pid [进程id]  

未生成调试信息

对于已运行且未生成调试信息的程序，我们可以重新编译出一个带调试信息的版本，再使用 file 命令将这个版本的符号表读取出来，此时我们再次 attach 程序，就能够进行调试了，并且不需要重新启动程序：

# 步骤一：重新编译一个带调试信息的版本
# 步骤二：使用file加载这个版本的符号表
file [程序名]
# 接下来的步骤与已生成调试信息的一样

调试 core 文件

当一个程序因为出错而导致异常中断的时候，操作系统会将程序当前的状态（如程序运行时的内存，寄存器状态，堆栈指针，内存管理信息）保存为一个 core 文件。我们可以通过使用 gdb 来调试这个文件，来迅速定位导致程序出错的问题。

配置 core 文件生成

首先我们需要使用 ulimit -a 命令查看系统有没有限制 core 文件的生成：

ulimit -c
unlimited # 代表没有限制
0         # 如果结果为零则代表无法生成，如果为其他数字则代表限制生成的个数

配置 coredump 生成，有临时配置和永久配置两种。

• 临时配置：只需要简单的命令即可，但是退出 bash 后就会失效。

  • $ ulimit -c unlimited  #表示不限制core文件大小
    $ ulimit -c n          #n为数字，表示core文件大小上限，单位为块，一块默认为512字节
    

• 永久配置：需要修改内核参数，指定 core 文件名、存放路径与永久配置。

  • mkdir -p /www/coredump/
    chmod 777 /www/coredump/
    /etc/profile
    ulimit -c unlimited
    /etc/security/limits.conf
    *          soft     core   unlimited
    echo "/www/coredump/core-%e-%p-%h-%t" > /proc/sys/kernel/core_pattern
    

调试 core 文件

这里以一个简单的访问空指针的示例来演示：

#include 
void fault_test(void) {
  
    *((int *)null) = 100;	//解引用空指针并尝试修改它的值
}
int main() {
  
    fault_test();
    return 0;
}

当我们编译后执行程序时，此时就会因为访问空指针而导致段错误：

gcc -g -o test_coredump test_coredump.c
./test_coredump
segmentation fault (core dumped)

此时查看 core 文件的位置：

cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %c %h %e

这时我们发现这个路径下并没有 core 文件，上述信息表明了 core 文件已经被系统转储，此时有两种方法获取到 core 文件：

• 修改生成路径：

  • # 直接在程序所在目录生成core文件
    echo  "core-%e-%p-%t" > /proc/sys/kernel/core_pattern
    

• 取出 core 文件：

  1. 执行 coredumpctl 命令，查看所有 coredump 的程序，找到我们需要调试的那个。
  2. 执行 coredumpctl -o 自定义core文件名 dump pid 取回 core 文件。

当生成完毕 core 文件后，执行以下命令开始调试：

gdb 程序名 core文件名

此时我们就能够看到 coredump 的原因：

[new lwp 1065384]
core was generated by `./test_coredump'.
program terminated with signal sigsegv, segmentation fault.
#0  fault_test () at test_coredump.c:4
4	    *((int *)null) = 100;

接着执行 where 命令就能够查看调用堆栈：

(gdb) where
#0  fault_test () at test_coredump.c:4
#1  0x0000000000400551 in main () at test_coredump.c:8

常用命令

在 gdb 中，最常用的命令有以下这些：

gdb 常用命令

下面就来详细的介绍这些命令。

断点

断点是最常用的调试功能之一，它可以让程序中断在需要的地方，从而方便我们对程序分析。gdb 中断点主要分为以下三类：

1. breakpoint。
2. watchpoint。
3. catchpoint。

breakpoint

可以根据行号、函数、条件生成断点，下面是相关命令以及对应的作用说明：

watchpoint

watchpoint 是一种特殊类型的断点，其类似于一个表达式的监视器，即当某个表达式改变了值时，它就会让 gdb 发出暂停执行的命令。

使用数据断点时，需要注意：

• 当监控变量为局部变量时，一旦局部变量失效，数据断点也会失效
• 如果监控的是指针变量p，则watch *p监控的是p所指内存数据的变化情况，而watch p监控的是p指针本身有没有改变指向

最常见的数据断点应用场景：定位堆上的结构体内部成员何时被修改。由于指针一般为局部变量，为了解决断点失效，一般有两种方法。

catchpoint

catchpoint 是捕获断点，其主要监测信号的产生。

调用栈

输出

变量信息

字符串

数组

指针

内存地址

使用 x 命令来打印内存的值，格式为 x/nfu addr，以 f 格式打印从 addr 开始的 n 个长度单元为 u 的内存值。

• n：输出单元的个数
• f：输出格式，如 x 表示以 16 进制输出，o 表示以 8 进制输出，默认为 x
• u：一个单元的长度，b 表示 1 个 byte，h 表示 2 个 byte（half word），w 表示 4 个 byte，g 表示 8 个 byte（giant word）

局部变量

结构体

函数跳转

多线程、多进程

多进程

gdb 在调试多进程程序（程序含 fork 调用）时，默认只追踪父进程。可以通过命令设置，实现只追踪父进程或子进程，或者同时调试父进程和子进程。

在调试多进程程序时候，默认情况下，除了当前调试的进程，其他进程都处于挂起状态，所以，如果需要在调试当前进程的时候，其他进程也能正常执行，那么通过设置 set schedule-multiple on 即可。

在默认情况下，gdb 只支持调试主进程（即 main），只有在 gdb 7.0 后才支持单独调试(调试父进程或者子进程)和同时调试多个进程。

多线程

默认调试多线程时，一旦程序中断，所有线程都将暂停。如果此时再继续执行当前线程，其他线程也会同时执行。

如果只关心当前线程，建议临时设置 scheduler-locking 为 on，避免其他线程同时运行，导致命中其他断点分散注意力。

其他

图形化

tui为terminal user interface的缩写，在启动时候指定-tui参数，或者调试时使用ctrl x a组合键，可进入或退出图形化界面。

汇编

其他工具

pstack

pstack 是一个 shell 脚本，用于打印正在运行的进程的栈跟踪信息。pstack 命令必须由相应进程的属主或 root 运行。可以使用 pstack 来确定进程挂起的位置。

使用方式如下：

pstack [pid]

ldd

当我们编译链接时找不到静态库而导致链接失败，又或者是编译成功，在运行时加载动态库失败时，我们可以使用 ldd 命令来分析该程序依赖了哪些库以及这些库所在的路径，从而解程序因缺少某个库文件而不能运行的一些问题。使用方式如下：

ldd 程序名

例如：

ldd test
	linux-vdso.so.1 (0x00007ffeefb2f000)
	libstdc  .so.6 => /lib64/libstdc  .so.6 (0x00007fa30f54a000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fa30f1c8000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa30efb0000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fa30ebeb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa30f8df000)

其中每一行的第一个参数程序依赖的库名，第二个则是系统所提供的对应的库（如果系统找不到，则会显示 not found），第三个是库加载的起始地址。

strings、c filt

c 为了支持函数重载功能，需要编译器在使用 name mangling 机制将符号表中的函数进行重命名，而我们使用 strings 就可以查看到重命名后的函数名：

strings 程序名

如果使用 c filt 工具，就可以根据符号表中的函数名，还原为原始的函数定义：

c  filt 重命名后的函数名

调试原理

当我们开始使用 gdb 开始调试时，系统首先会启动一个 gdb 进程，紧接着这个进程会 fork 出一个子进程来控制被调试程序，它会执行以下操作：

1. 调用 ptrace(ptrace_traceme) 来让 gdb 进程接管本进程的执行。
2. 通过 execv 来将被调试程序替换到子进程中。

详细流程如下图所示：

gdb 执行流程图

接下来就介绍里面最关键的 ptrace。

ptrace

ptrace 是 linux 内核提供的一个用于进程跟踪的系统调用，通过它，一个进程（gdb）可以读写另外一个进程（被调试进程）的指令空间、数据空间、堆栈和寄存器的值，并且 gdb 进程接管了被调试进程的所有信号，这样一来，被调试进程的执行就被 gdb 控制，从而达到调试的目的。

gdb 进程与被调试进程

ptrace 的定义如下：

#include 
long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data)

• enum __ptrace_request request：指示了 ptrace 要执行的命令。
• pid_t pid：指示 ptrace 要跟踪的进程
• void *addr：指示要监控的内存地址
• void *data：存放读取出的或者要写入的数据。

调试运行中程序

如果想要调试一个已经执行的进程，就需要在 gdb 进程中调用 ptrace(ptrace_attach,...)，此时 gdb 进程会 attach 已经执行的被调试进程，将其收养为自己的子进程，接着会向被调试进程发送一个 sigsto 信号，当被调试进程接收到这个信号时，就会暂时执行并进入 task_stoped 状态，表示其已经准备好接受调试。

attach 的一些限制：不予许 attach 自己；不允许多次 attach 到同一个进程；不允许 attach 1 号进程；

gdb 调试已运行程序

断点 break

当我们使用 break 命令设置断点的时候，gdb 首先会将原来的汇编代码存储到一个断点链表中，接着会在对应的汇编代码的位置插入一个 int3 中断指令。

当被调试的程序运行到这个位置时，就会执行 int3 指令，此时会发生软中断，接着内核会向被调试进程发送一个 sigtrap 信号，由于当前 gdb 通过 ptrace 接管了被调试进程，所以这个信号自然又转发到了 gdb 进程中。gdb 此时会对比当前停止的位置和断点链表中存储的断点位置，将该位置的代码恢复成断点链表中存储的原来的代码，接着将程序计数器（pc 指针）回退一步，指向用户 break 的位置。

此时就达到了断点的目的，接着 gdb 会一直等待用户输入调试指令。

单步 next

当我们使用 next 执行单步命令时，此时 gdb 会控制其执行一行代码，它首先会计算出这一行代码所对应的汇编代码的位置，接着控制程序计数器一直往下执行，直到执行到这个位置时就会停下来，继续等待用户输入调试指令。

这个功能其实借助 ptrace 就可以直接实现，只需要在第一个参数中传递 ptrace_singlestep 即可。