即使是复杂的函数，也有几种方法可以单步调试，所以下次在排除代码故障时，可以尝试一下这些 GDB 技术。

调试器 是一个可以运行你的代码并检查问题的软件。GNU Debugger（GBD）是最流行的调试器之一，在这篇文章中，我研究了 GDB 的 step 命令和其他几种常见情况的相关命令。step 是一个被广泛使用的命令，但它有一些人们不太了解的地方，可能会使得他们十分困惑。此外，还有一些方法可以在不使用 step 命令的情况下进入一个函数，比如使用不太知名的 advance 命令。

1、无调试符号

考虑以下这个简单的示例程序：

#include <stdio.h>


int num() {
    return 2;
}

void bar(int i) {
    printf("i = %d\n", i);
}


int main() {
    bar(num());
    return 0;
}

如果你在没有 调试符号 debugging sysbols 的情况下进行编译（LCTT 译注：即在使用 gcc 编译程序时没有写 -g 选项），然后在 bar 上设置一个断点，然后尝试在这个函数内使用 step 来单步执行语句。GDB 会给出一个 没有行号信息 no line number information 的错误信息。

gcc exmp.c -o exmp
gdb ./exmp
(gdb) b bar
Breakpoint 1 at 0x401135
(gdb) r
Starting program: /home/ahajkova/exmp
Breakpoint 1, 0x0000000000401135 in bar ()
(gdb) step
Single stepping until exit from function bar,
which has no line number information.
i = 2
0x0000000000401168 in main ()

2、stepi 命令

但是你仍然可以在没有行号信息的函数内部单步执行语句，但要使用 stepi 命令来代替 step。stepi 一次只执行一条指令。当使用 GDB 的 stepi 命令时，先做 display/i $pc 通常很有用，这会在每一步之后显示 程序计数器 program counter 的值和相应的 机器指令 machine instruction ：

(gdb) b bar
Breakpoint 1 at 0x401135
(gdb) r
Starting program: /home/ahajkova/exmp
Breakpoint 1, 0x0000000000401135 in bar ()
(gdb) display/i $pc
1: x/i $pc
=> 0x401135 <bar+4>: sub $0x10,%rsp

在上述的 display 命令中，i 代表机器指令，$pc 表示程序计数器寄存器（即 PC 寄存器）。

使用 info registers 命令，来打印寄存器的内容，也是十分有用的。

(gdb) info registers
rax 0x2 2
rbx 0x7fffffffdbc8 140737488346056
rcx 0x403e18 4210200
(gdb) print $rax
$1 = 2
(gdb) stepi
0x0000000000401139 in bar ()
1: x/i $pc
=> 0x401139 <bar+8>: mov %edi,-0x4(%rbp)

3、复杂的函数调用

在带调试符号的 -g 选项，重新编译示例程序后，你可以使用行号在 main 中 bar 调用上设置断点，然后再单步执行 bar 函数的语句：

gcc -g exmp.c -o exmp
gdb ./exmp
(gdb) b exmp.c:14
Breakpoint 1 at 0x401157: file exmp.c, line 14.
(gdb) r
Starting program: /home/ahajkova/exmp
Breakpoint 1, main () at exmp.c:14
14 bar(num());

接下来，用 step，来单步执行 bar() 函数的语句：

(gdb) step
num () at exmp.c:4
4 return 2;

函数调用的参数需要在实际的函数调用之前进行处理，bar() 函数的参数是 num() 函数，所以 num() 会在 bar() 被调用之前执行。但是，通过 GDB 调试，你怎么才能如愿以偿地进入 bar() 函数呢？你可以使用 finish 命令，并再次使用 step 命令。

(gdb) finish
Run till exit from #0 num () at exmp.c:4
0x0000000000401161 in main () at exmp.c:14
14 bar(num());
Value returned is $1 = 2
(gdb) step
bar (i=2) at exmp.c:9
9 printf("i = %d\n", i);

4、tbreak 命令

tbreak 命令会设置一个临时断点。如果你不想设置永久断点，那么这个命令是很有用的。举个例子?，你想进入一个复杂的函数调用，例如 f(g(h()), i(j()), ...)，在这种情况下，你需要一个很长的 step/finish/step 序列，才能到达 f 函数。如果你设置一个临时断点，然后再使用 continue 命令，这样就不需要以上的序列了。为了证明这一点，你需要像以前一样将断点设置在 main 的 bar 调用上。然后在 bar 上设置临时断点。当到达该临时断点后，临时断点会被自动删除。

(gdb) r
Starting program: /home/ahajkova/exmp
Breakpoint 1, main () at exmp.c:14
14 bar(num());
(gdb) tbreak bar
Temporary breakpoint 2 at 0x40113c: file exmp.c, line 9.

在调用 bar 的时候遇到断点，并在 bar 上设置临时断点后，你只需要使用 continue 继续运行直到 bar 结束。

(gdb) continue
Continuing.
Temporary breakpoint 2, bar (i=2) at exmp.c:9
9 printf("i = %d\n", i);

5、disable 命令

类似地，你也可以在 bar 上设置一个正常的断点，然后执行 continue，然后在不再需要第二个断点时，使用 disable 命令禁用这个断点，这样也能达到与 tbreak 相同的效果。

(gdb) b exmp.c:14
Breakpoint 1 at 0x401157: file exmp.c, line 14.
(gdb) r
Starting program: /home/ahajkova/exmp
Breakpoint 1, main () at exmp.c:14
14 bar(num());
(gdb) b bar
Breakpoint 2 at 0x40113c: file exmp.c, line 9.
(gdb) c
Continuing.
Breakpoint 2, bar (i=2) at exmp.c:9
9 printf("i = %d\n", i);
(gdb) disable 2

正如你所看到的，info breakpoints 命令在 Enb 列下显示为 n，这意味着这个断点已被禁用。但你也能在再次需要这个断点时，再启用它。

(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000401157 in main at exmp.c:14
breakpoint already hit 1 time
2 breakpoint keep n 0x000000000040113c in bar at exmp.c:9
breakpoint already hit 1 time
(gdb) enable 2
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000040116a in main at exmp.c:19
breakpoint already hit 1 time
2 breakpoint keep y 0x0000000000401158 in bar at exmp.c:14
breakpoint already hit 1 time

6、advance 命令运行程序到指定的位置

另一个进入函数内部的方法是 advance 命令。你可以简单地用 advance bar，来代替 tbreak bar ; continue。这一命令会将程序继续运行到指定的位置。

advance 命令的一个很棒的地方在于：如果程序并没有到达你试图进入的位置，那么 GDB 将在当前函数运行完成后停止。因此，程序的执行会受到限制：

Breakpoint 1 at 0x401157: file exmp.c, line 14.
(gdb) r
Starting program: /home/ahajkova/exmp
Breakpoint 1, main () at exmp.c:14
14 bar(num());
(gdb) advance bar
bar (i=2) at exmp.c:9
9 printf("i = %d\n", i);

7、skip 命令

进入 bar 函数的另一种方式是使用 skip num 命令：

(gdb) b exmp.c:14
Breakpoint 1 at 0x401157: file exmp.c, line 14.
(gdb) skip num
Function num will be skipped when stepping.
(gdb) r
Starting program: /home/ahajkova/exmp
Breakpoint 1, main () at exmp.c:14
14 bar(num());
(gdb) step
bar (i=2) at exmp.c:9
9 printf("i = %d\n", i);

请使用 info skip 命令，来了解 GDB 跳过了哪些函数。num() 函数被标记为 y，表示跳过了 num() 函数：

(gdb) info skip
Num Enb Glob File RE Function
1 y n <none> n num

如果不再需要 skip，可以禁用（并稍后重新启用）或完全删除它。你可以添加另一个 skip，并禁用第一个 skip，然后全部删除。要禁用某个 skip，必须指定其编号（例如，skip disable 1），如果没有指定，则会禁用所有的 skip。启用或删除 skip 的工作原理相同：

(gdb) skip bar
(gdb) skip disable 1
(gdb) info skip
Num Enb Glob File RE Function
1 n n <none> n num
2 y n <none> n bar
(gdb) skip delete
(gdb) info skip
Not skipping any files or functions.

GDB 的 step 命令

使用 GDB 的 step 命令是调试程序的一个有用工具。即使是复杂的函数，也有几种方法可以单步调试这些函数，所以下次你在排除代码问题的时候，可以尝试一下这些 GDB 技术。

via: https://opensource.com/article/22/12/gdb-step-command

作者：Alexandra 选题：lkxed 译者：chai001125 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

GNU 调试器是一个发现程序缺陷的强大工具。

如果你是一个程序员，想在你的软件增加某些功能，你首先考虑实现它的方法：例如写一个方法、定义一个类，或者创建新的数据类型。然后你用编译器或解释器可以理解的编程语言来实现这个功能。但是，如果你觉得你所有代码都正确，但是编译器或解释器依然无法理解你的指令怎么办？如果软件大多数情况下都运行良好，但是在某些环境下出现缺陷怎么办？这种情况下，你得知道如何正确使用调试器找到问题的根源。

GNU 调试器 GNU Project Debugger （GDB）是一个发现项目缺陷的强大工具。它通过追踪程序运行过程中发生了什么来帮助你发现程序错误或崩溃的原因。（LCTT 校注：GDB 全程是“GNU Project Debugger”，即 “GNU 项目调试器”，但是通常我们简称为“GNU 调试器”）

本文是 GDB 基本用法的实践教程。请跟随示例，打开命令行并克隆此仓库：

git clone https://github.com/hANSIc99/core_dump_example.git

快捷方式

GDB 的每条命令都可以缩短。例如：显示设定的断点的 info break 命令可以被缩短为 i break。你可能在其他地方看到过这种缩写，但在本文中，为了清晰展现使用的函数，我将所写出整个命令。

命令行参数

你可以将 GDB 附加到每个可执行文件。进入你克隆的仓库（core_dump_example），运行 make 进行编译。你现在能看到一个名为 coredump 的可执行文件。（更多信息，请参考我的文章《创建和调试 Linux 的转储文件》。）

要将 GDB 附加到这个可执行文件，请输入: gdb coredump。

你的输出应如下所示：

返回结果显示没有找到调试符号。

调试信息是 目标文件 object file （可执行文件）的组成部分，调试信息包括数据类型、函数签名、源代码和操作码之间的关系。此时，你有两种选择：

• 继续调试汇编代码（参见下文“无符号调试”）
• 使用调试信息进行编译，参见下一节内容

使用调试信息进行编译

为了在二进制文件中包含调试信息，你必须重新编译。打开 Makefile，删除第 9 行的注释标签（#）后重新编译：

CFLAGS =-Wall -Werror -std=c++11 -g

-g 告诉编译器包含调试信息。运行 make clean，接着运行 make，然后再次调用 GDB。你得到如下输出后就可以调试代码了：

新增的调试信息会增加可执行文件的大小。在这种情况下，执行文件增加了 2.5 倍（从 26,088 字节 增加到 65,480 字节）。

输入 run -c1，使用 -c1 开关启动程序。当程序运行到达 State_4 时将崩溃：

你可以检索有关程序的其他信息，info source 命令提供了当前文件的信息：

• 101 行代码
• 语言: C++
• 编译器（版本、调优、架构、调试标志、语言标准）
• 调试格式：DWARF 2
• 没有预处理器宏指令（使用 GCC 编译时，宏仅在 使用 -g3 标志编译 时可用）。

info shared 命令打印了动态库列表机器在虚拟地址空间的地址，它们在启动时被加载到该地址，以便程序运行：

如果你想了解 Linux 中的库处理方式，请参见我的文章 在 Linux 中如何处理动态库和静态库。

调试程序

你可能已经注意到，你可以在 GDB 中使用 run 命令启动程序。run 命令接受命令行参数，就像从控制台启动程序一样。-c1 开关会导致程序在第 4 阶段崩溃。要从头开始运行程序，你不用退出 GDB，只需再次运行 run 命令。如果没有 -c1 开关，程序将陷入死循环，你必须使用 Ctrl+C 来结束死循环。

你也可以一步一步运行程序。在 C/C++ 中，入口是 main 函数。使用 list main 命令打开显示 main 函数的部分源代码：

main 函数在第 33 行，因此可以输入 break 33 在 33 行添加断点:

输入 run 运行程序。正如预期的那样，程序在 main 函数处停止。输入 layout src 并排查看源代码：

你现在处于 GDB 的文本用户界面（TUI）模式。可以使用键盘向上和向下箭头键滚动查看源代码。

GDB 高亮显示当前执行行。你可以输入 next（n）命令逐行执行命令。如果你没有指定新的命令，GBD 会执行上一条命令。要逐行运行代码，只需按回车键。

有时，你会发现文本的输出有点显示不正常：

如果发生这种情况，请按 Ctrl+L 重置屏幕。

使用 Ctrl+X+A 可以随时进入和退出 TUI 模式。你可以在手册中找到 其他的键绑定 。

要退出 GDB，只需输入 quit。

设置监察点

这个示例程序的核心是一个在无限循环中运行的状态机。n_state 变量枚举了当前所有状态：

while(true){
        switch(n_state){
        case State_1:
                std::cout << "State_1 reached" << std::flush;
                n_state = State_2;
                break;
        case State_2:
                std::cout << "State_2 reached" << std::flush;
                n_state = State_3;
                break;
        
        (.....)
        
        }
}

如果你希望当 n_state 的值为 State_5 时停止程序。为此，请在 main 函数处停止程序并为 n_state 设置监察点：

watch n_state == State_5

只有当所需的变量在当前上下文中可用时，使用变量名设置监察点才有效。

当你输入 continue 继续运行程序时，你会得到如下输出：

如果你继续运行程序，当监察点表达式评估为 false 时 GDB 将停止：

你可以为一般的值变化、特定的值、读取或写入时来设置监察点。

更改断点和监察点

输入 info watchpoints 打印先前设置的监察点列表：

删除断点和监察点

如你所见，监察点就是数字。要删除特定的监察点，请先输入 delete 后输入监察点的编号。例如，我的监察点编号为 2；要删除此监察点，输入 delete 2。

注意： 如果你使用 delete 而没有指定数字，所有 监察点和断点将被删除。

这同样适用于断点。在下面的截屏中，我添加了几个断点，输入 info breakpoint 打印断点列表：

要删除单个断点，请先输入 delete 后输入断点的编号。另外一种方式：你可以通过指定断点的行号来删除断点。例如，clear 78 命令将删除第 78 行设置的断点号 7。

禁用或启用断点和监察点

除了删除断点或监察点之外，你可以通过输入 disable，后输入编号禁用断点或监察点。在下文中，断点 3 和 4 被禁用，并在代码窗口中用减号标记：

也可以通过输入类似 disable 2 - 4 修改某个范围内的断点或监察点。如果要重新激活这些点，请输入 enable，然后输入它们的编号。

条件断点

首先，输入 delete 删除所有断点和监察点。你仍然想使程序停在 main 函数处，如果你不想指定行号，可以通过直接指明该函数来添加断点。输入 break main 从而在 main 函数处添加断点。

输入 run 从头开始运行程序，程序将在 main 函数处停止。

main 函数包括变量 n_state_3_count，当状态机达到状态 3 时，该变量会递增。

基于 n_state_3_count 的值添加一个条件断点，请输入：

break 54 if n_state_3_count == 3

继续运行程序。程序将在第 54 行停止之前运行状态机 3 次。要查看 n_state_3_count 的值，请输入：

print n_state_3_count

使断点成为条件断点

你也可以使现有断点成为条件断点。用 clear 54 命令删除最近添加的断点，并通过输入 break 54 命令添加一个简单的断点。你可以输入以下内容使此断点成为条件断点：

condition 3 n_state_3_count == 9

3 指的是断点编号。

在其他源文件中设置断点

如果你的程序由多个源文件组成，你可以在行号前指定文件名来设置断点，例如，break main. cpp:54。

捕捉点

除了断点和监察点之外，你还可以设置捕获点。捕获点适用于执行系统调用、加载共享库或引发异常等事件。

要捕获用于写入 STDOUT 的 write 系统调用，请输入：

catch syscall write

每当程序写入控制台输出时，GDB 将中断执行。

在手册中，你可以找到一整章关于 断点、监察点和捕捉点 的内容。

评估和操作符号

用 print 命令可以打印变量的值。一般语法是 print <表达式> <值>。修改变量的值，请输入：

set variable <variable-name> <new-value>.

在下面的截屏中，我将变量 n_state_3_count 的值设为 123。

/x 表达式以十六进制打印值；使用 & 运算符，你可以打印虚拟地址空间内的地址。

如果你不确定某个符号的数据类型，可以使用 whatis 来查明。

如果你要列出 main 函数范围内可用的所有变量，请输入 info scope main :

DW_OP_fbreg 值是指基于当前子程序的堆栈偏移量。

或者，如果你已经在一个函数中并且想要列出当前堆栈帧上的所有变量，你可以使用 info locals :

查看手册以了解更多 检查符号 的内容。

附加调试到一个正在运行的进程

gdb attach <进程 ID> 命令允许你通过指定进程 ID（PID）附加到一个已经在运行的进程进行调试。幸运的是，coredump 程序将其当前 PID 打印到屏幕上，因此你不必使用 ps 或 top 手动查找 PID。

启动 coredump 应用程序的一个实例：

./coredump

操作系统显示 PID 为 2849。打开一个单独的控制台窗口，移动到 coredump 应用程序的根目录，然后用 GDB 附加到该进程进行调试：

gdb attach 2849

当你用 GDB 附加到进程时，GDB 会立即停止进程运行。输入 layout src 和 backtrace 来检查调用堆栈：

输出显示在 main.cpp 第 92 行调用 std::this_thread::sleep_for<...>(. ..) 函数时进程中断。

只要你退出 GDB，该进程将继续运行。

你可以在 GDB 手册中找到有关 附加调试正在运行的进程 的更多信息。

在堆栈中移动

在命令窗口，输入 up 两次可以在堆栈中向上移动到 main.cpp :

通常，编译器将为每个函数或方法创建一个子程序。每个子程序都有自己的栈帧，所以在栈帧中向上移动意味着在调用栈中向上移动。

你可以在手册中找到有关 堆栈计算 的更多信息。

指定源文件

当调试一个已经在运行的进程时，GDB 将在当前工作目录中寻找源文件。你也可以使用 目录命令 手动指定源目录。

评估转储文件

阅读 创建和调试 Linux 的转储文件 了解有关此主题的信息。

参考文章太长，简单来说就是：

1. 假设你使用的是最新版本的 Fedora
2. 使用 -c1 开关调用 coredump：coredump -c1

3. 使用 GDB 加载最新的转储文件：coredumpctl debug
4. 打开 TUI 模式并输入 layout src

backtrace 的输出显示崩溃发生在距离 main.cpp 五个栈帧之外。回车直接跳转到 main.cpp 中的错误代码行：

看源码发现程序试图释放一个内存管理函数没有返回的指针。这会导致未定义的行为并引起 SIGABRT。

无符号调试

如果没有源代码，调试就会变得非常困难。当我在尝试解决逆向工程的挑战时，我第一次体验到了这一点。了解一些 汇编语言 的知识会很有用。

我们用例子看看它是如何运行的。

找到根目录，打开 Makefile，然后像下面一样编辑第 9 行：

CFLAGS =-Wall -Werror -std=c++11 #-g

要重新编译程序，先运行 make clean，再运行 make，最后启动 GDB。该程序不再有任何调试符号来引导源代码的走向。

info file 命令显示二进制文件的内存区域和入口点：

.text 区段始终从入口点开始，其中包含实际的操作码。要在入口点添加断点，输入 break *0x401110 然后输入 run 开始运行程序：

要在某个地址设置断点，使用取消引用运算符 * 来指定地址。

选择反汇编程序风格

在深入研究汇编之前，你可以选择要使用的 汇编风格。 GDB 默认是 AT&T，但我更喜欢 Intel 语法。变更风格如下：

set disassembly-flavor intel

现在输入 layout asm 调出汇编代码窗口，输入 layout reg 调出寄存器窗口。你现在应该看到如下输出：

保存配置文件

尽管你已经输入了许多命令，但实际上还没有开始调试。如果你正在大量调试应用程序或尝试解决逆向工程的难题，则将 GDB 特定设置保存在文件中会很有用。

该项目的 GitHub 存储库中的 gdbinit 配置文件包含最近使用的命令：

set disassembly-flavor intel
set write on
break *0x401110
run -c2
layout asm
layout reg

set write on 命令使你能够在程序运行期间修改二进制文件。

退出 GDB 并使用配置文件重新启动 GDB ： gdb -x gdbinit coredump。

阅读指令

应用 c2 开关后，程序将崩溃。程序在入口函数处停止，因此你必须写入 continue 才能继续运行：

idiv 指令进行整数除法运算：RAX 寄存器中为被除数，指定参数为除数。商被加载到 RAX 寄存器中，余数被加载到 RDX 中。

从寄存器角度，你可以看到 RAX 包含 5，因此你必须找出存储堆栈中位置为 rbp-0x4 的值。

读取内存

要读取原始内存内容，你必须指定比读取符号更多的参数。在汇编输出中向上滚动一点，可以看到堆栈的划分：

你最感兴趣的应该是 rbp-0x4 的值，因为它是 idiv 的存储参数。你可以从截图中看到rbp-0x8 位置的下一个变量，所以 rbp-0x4 位置的变量是 4 字节宽。

在 GDB 中，你可以使用 x 命令查看任何内存内容：

x/ < 可选参数 n、f、u > < 内存地址 addr >

可选参数：

• n：单元大小的重复计数（默认值：1）
• f：格式说明符，如 printf

• u：单元大小

  • b：字节
  • h：半字（2 个字节）
  • w: 字（4 个字节）（默认）
  • g: 双字（8 个字节）

要打印 rbp-0x4 的值，请输入 x/u $rbp-4 :

如果你能记住这种模式，则可以直接查看内存。参见手册中的 查看内存 部分。

操作汇编

子程序 zeroDivide() 发生运算异常。当你用向上箭头键向上滚动一点时，你会找到下面信息：

0x401211 <_Z10zeroDividev>              push   rbp
0x401212 <_Z10zeroDividev+1>            mov    rbp,rsp

这被称为 函数前言：

1. 调用函数的基指针（rbp）存放在栈上
2. 栈指针（rsp）的值被加载到基指针（rbp）

完全跳过这个子程序。你可以使用 backtrace 查看调用堆栈。在 main 函数之前只有一个堆栈帧，所以你可以用一次 up 回到 main :

在你的 main 函数中，你会找到下面信息:

0x401431 <main+497>     cmp    BYTE PTR [rbp-0x12],0x0
0x401435 <main+501>     je     0x40145f <main+543>
0x401437 <main+503>     call   0x401211<_Z10zeroDividev>

子程序 zeroDivide() 仅在 jump equal (je) 为 true 时进入。你可以轻松地将其替换为 jump-not-equal (jne) 指令，该指令的操作码为 0x75（假设你使用的是 x86/64 架构；其他架构上的操作码不同）。输入 run 重新启动程序。当程序在入口函数处停止时，设置操作码：

set *(unsigned char*)0x401435 = 0x75

最后，输入 continue 。该程序将跳过子程序 zeroDivide() 并且不会再崩溃。

总结

你会在许多集成开发环境（IDE）中发现 GDB 运行在后台，包括 Qt Creator 和 VSCodium 的 本地调试 扩展。

了解如何充分利用 GDB 的功能很有用。一般情况下，并非所有 GDB 的功能都可以在 IDE 中使用，因此你可以从命令行使用 GDB 的经验中受益。

via: https://opensource.com/article/21/1/gnu-project-debugger

作者：Stephan Avenwedde 选题：lkxed 译者：Maisie-x 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

昨天我和一些人在闲聊的时候，他们说他们并不真正了解栈是如何工作的，而且也不知道如何去查看栈空间。

这是一个快速教程，介绍如何使用 GDB 查看 C 程序的栈空间。我认为这对于 Rust 程序来说也是相似的。但我这里仍然使用 C 语言，因为我发现用它更简单，而且用 C 语言也更容易写出错误的程序。

我们的测试程序

这里是一个简单的 C 程序，声明了一些变量，从标准输入读取两个字符串。一个字符串在堆上，另一个字符串在栈上。

#include <stdio.h>
#include <stdlib.h>

int main() {
    char stack_string[10] = "stack";
    int x = 10;
    char *heap_string;

    heap_string = malloc(50);

    printf("Enter a string for the stack: ");
    gets(stack_string);
    printf("Enter a string for the heap: ");
    gets(heap_string);
    printf("Stack string is: %s\n", stack_string);
    printf("Heap string is: %s\n", heap_string);
    printf("x is: %d\n", x);
}

这个程序使用了一个你可能从来不会使用的极为不安全的函数 gets 。但我是故意这样写的。当出现错误的时候，你就知道是为什么了。

第 0 步：编译这个程序

我们使用 gcc -g -O0 test.c -o test 命令来编译这个程序。

-g 选项会在编译程序中将调式信息也编译进去。这将会使我们查看我们的变量更加容易。

-O0 选项告诉 gcc 不要进行优化，我要确保我们的 x 变量不会被优化掉。

第一步：启动 GDB

像这样启动 GDB：

$ gdb ./test

它打印出一些 GPL 信息，然后给出一个提示符。让我们在 main 函数这里设置一个断点：

(gdb) b main

然后我们就可以运行程序：

(gdb) b main
Starting program: /home/bork/work/homepage/test
Breakpoint 1, 0x000055555555516d in main ()

(gdb) run
Starting program: /home/bork/work/homepage/test

Breakpoint 1, main () at test.c:4
4   int main() {

好了，现在程序已经运行起来了。我们就可以开始查看栈空间了。

第二步：查看我们变量的地址

让我们从了解我们的变量开始。它们每个都在内存中有一个地址，我们可以像这样打印出来：

(gdb) p &x
$3 = (int *) 0x7fffffffe27c
(gdb) p &heap_string
$2 = (char **) 0x7fffffffe280
(gdb) p &stack_string
$4 = (char (*)[10]) 0x7fffffffe28e

因此，如果我们查看那些地址的堆栈，那我们应该能够看到所有的这些变量！

概念：栈指针

我们将需要使用栈指针，因此我将尽力对其进行快速解释。

有一个名为 ESP 的 x86 寄存器，称为“ 栈指针 stack pointer ”。 基本上，它是当前函数的栈起始地址。 在 GDB 中，你可以使用 $sp 来访问它。 当你调用新函数或从函数返回时，栈指针的值会更改。

第三步：在 main 函数开始的时候，我们查看一下在栈上的变量

首先，让我们看一下 main 函数开始时的栈。 现在是我们的堆栈指针的值：

(gdb) p $sp
$7 = (void *) 0x7fffffffe270

因此，我们当前函数的栈起始地址是 0x7fffffffe270，酷极了。

现在，让我们使用 GDB 打印出当前函数堆栈开始后的前 40 个字（即 160 个字节）。 某些内存可能不是栈的一部分，因为我不太确定这里的堆栈有多大。 但是至少开始的地方是栈的一部分。

我已粗体显示了 stack_string，heap_string 和 x 变量的位置，并改变了颜色：

• x 是红色字体，并且起始地址是 0x7fffffffe27c
• heap_string 是蓝色字体，起始地址是 0x7fffffffe280
• stack_string 是紫色字体，起始地址是 0x7fffffffe28e

你可能会在这里注意到的一件奇怪的事情是 x 的值是 0x5555，但是我们将 x 设置为 10！ 那是因为直到我们的 main 函数运行之后才真正设置 x ，而我们现在才到了 main 最开始的地方。

第三步：运行到第十行代码后，再次查看一下我们的堆栈

让我们跳过几行，等待变量实际设置为其初始化值。 到第 10 行时，x 应该设置为 10。

首先我们需要设置另一个断点：

(gdb) b test.c:10
Breakpoint 2 at 0x5555555551a9: file test.c, line 11.

然后继续执行程序：

(gdb) continue
Continuing.

Breakpoint 2, main () at test.c:11
11      printf("Enter a string for the stack: ");

好的！ 让我们再来看看堆栈里的内容！ gdb 在这里格式化字节的方式略有不同，实际上我也不太关心这些（LCTT 译注:可以查看 GDB 手册中 x 命令，可以指定 c 来控制输出的格式）。 这里提醒一下你，我们的变量在栈上的位置：

• x 是红色字体，并且起始地址是 0x7fffffffe27c
• heap_string 是蓝色字体，起始地址是 0x7fffffffe280
• stack_string 是紫色字体，起始地址是 0x7fffffffe28e

在继续往下看之前，这里有一些有趣的事情要讨论。

stack_string 在内存中是如何表示的

现在（第 10 行），stack_string 被设置为字符串stack。 让我们看看它在内存中的表示方式。

我们可以像这样打印出字符串中的字节（LCTT 译注：可以通过 c 选项直接显示为字符）：

(gdb) x/10x stack_string
0x7fffffffe28e: 0x73    0x74    0x61    0x63    0x6b    0x00    0x00    0x00
0x7fffffffe296: 0x00    0x00

stack 是一个长度为 5 的字符串，相对应 5 个 ASCII 码- 0x73、0x74、0x61、0x63 和 0x6b。0x73 是字符 s 的 ASCII 码。 0x74 是 t 的 ASCII 码。等等...

同时我们也使用 x/1s 可以让 GDB 以字符串的方式显示：

(gdb) x/1s stack_string
0x7fffffffe28e: "stack"

heap_string 与 stack_string 有何不同

你已经注意到了 stack_string 和 heap_string 在栈上的表示非常不同：

• stack_string 是一段字符串内容（stack）
• heap_string 是一个指针，指向内存中的某个位置

这里是 heap_string 变量在内存中的内容：

0xa0  0x92  0x55  0x55  0x55  0x55  0x00  0x00

这些字节实际上应该是从右向左读：因为 x86 是小端模式，因此，heap_string 中所存放的内存地址 0x5555555592a0

另一种方式查看 heap_string 中存放的内存地址就是使用 p 命令直接打印 ：

(gdb) p heap_string
$6 = 0x5555555592a0 ""

整数 x 的字节表示

x 是一个 32 位的整数，可由 0x0a 0x00 0x00 0x00 来表示。

我们还是需要反向来读取这些字节（和我们读取 heap_string 需要反过来读是一样的），因此这个数表示的是 0x000000000a 或者是 0x0a，它是一个数字 10;

这就让我把把 x 设置成了 10。

第四步：从标准输入读取

好了，现在我们已经初始化我们的变量，我们来看一下当这段程序运行的时候，栈空间会如何变化：

printf("Enter a string for the stack: ");
gets(stack_string);
printf("Enter a string for the heap: ");
gets(heap_string);

我们需要设置另外一个断点：

(gdb) b test.c:16
Breakpoint 3 at 0x555555555205: file test.c, line 16.

然后继续执行程序：

(gdb) continue
Continuing.

我们输入两个字符串，为栈上存储的变量输入 123456789012 并且为在堆上存储的变量输入 bananas;

让我们先来看一下 stack_string（这里有一个缓存区溢出）

(gdb) x/1s stack_string
0x7fffffffe28e: "123456789012"

这看起来相当正常，对吗？我们输入了 12345679012，然后现在它也被设置成了 12345679012（LCTT 译注：实测 gcc 8.3 环境下，会直接段错误）。

但是现在有一些很奇怪的事。这是我们程序的栈空间的内容。有一些紫色高亮的内容。

令人奇怪的是 stack_string 只支持 10 个字节。但是现在当我们输入了 13 个字符以后，发生了什么？

这是一个典型的缓冲区溢出，stack_string 将自己的数据写在了程序中的其他地方。在我们的案例中，这还没有造成问题，但它会使你的程序崩溃，或者更糟糕的是，使你面临非常糟糕的安全问题。

例如，假设 stack_string 在内存里的位置刚好在 heap_string 之前。那我们就可能覆盖 heap_string 所指向的地址。我并不确定 stack_string 之后的内存里有一些什么。但我们也许可以用它来做一些诡异的事情。

确实检测到了有缓存区溢出

当我故意写很多字符的时候：

 ./test
Enter a string for the stack: 01234567891324143
Enter a string for the heap: adsf
Stack string is: 01234567891324143
Heap string is: adsf
x is: 10
*** stack smashing detected ***: terminated
fish: Job 1, './test' terminated by signal SIGABRT (Abort)

这里我猜是 stack_string 已经到达了这个函数栈的底部，因此额外的字符将会被写在另一块内存中。

当你故意去使用这个安全漏洞时，它被称为“堆栈粉碎”，而且不知何故有东西在检测这种情况的发生。

我也觉得这很有趣，虽然程序被杀死了，但是当缓冲区溢出发生时它不会立即被杀死——在缓冲区溢出之后再运行几行代码，程序才会被杀死。 好奇怪！

这些就是关于缓存区溢出的所有内容。

现在我们来看一下 heap_string

我们仍然将 bananas 输入到 heap_string 变量中。让我们来看一下内存中的样子。

这是在我们读取了字符串以后，heap_string 在栈空间上的样子：

需要注意的是，这里的值是一个地址。并且这个地址并没有改变，但是我们来看一下指向的内存上的内容。

(gdb) x/10x 0x5555555592a0
0x5555555592a0: 0x62    0x61    0x6e    0x61    0x6e    0x61    0x73    0x00
0x5555555592a8: 0x00    0x00

看到了吗，这就是字符串 bananas 的字节表示。这些字节并不在栈空间上。他们存在于内存中的堆上。

堆和栈到底在哪里？

我们已经讨论过栈和堆是不同的内存区域，但是你怎么知道它们在内存中的位置呢？

每个进程都有一个名为 /proc/$PID/maps 的文件，它显示了每个进程的内存映射。 在这里你可以看到其中的栈和堆。

$ cat /proc/24963/maps
... lots of stuff omitted ...
555555559000-55555557a000 rw-p 00000000 00:00 0                          [heap]
... lots of stuff omitted ...
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]

需要注意的一件事是，这里堆地址以 0x5555 开头，栈地址以 0x7fffff 开头。 所以很容易区分栈上的地址和堆上的地址之间的区别。

像这样使用 gdb 真的很有帮助

这有点像旋风之旅，虽然我没有解释所有内容，但希望看到数据在内存中的实际情况可以使你更清楚地了解堆栈的实际情况。

我真的建议像这样来把玩一下 gdb —— 即使你不理解你在内存中看到的每一件事，我发现实际上像这样看到我程序内存中的数据会使抽象的概念，比如“栈”和“堆”和“指针”更容易理解。

更多练习

一些关于思考栈的后续练习的想法（没有特定的顺序）：

• 尝试将另一个函数添加到 test.c 并在该函数的开头创建一个断点，看看是否可以从 main 中找到堆栈！ 他们说当你调用一个函数时“堆栈会变小”，你能在 gdb 中看到这种情况吗？
• 从函数返回一个指向栈上字符串的指针，看看哪里出了问题。 为什么返回指向栈上字符串的指针是不好的？
• 尝试在 C 中引起堆栈溢出，并尝试通过在 gdb 中查看堆栈溢出来准确理解会发生什么！
• 查看 Rust 程序中的堆栈并尝试找到变量！
• 在 噩梦课程 中尝试一些缓冲区溢出挑战。每个问题的答案写在 README 文件中，因此如果你不想被宠坏，请避免先去看答案。 所有这些挑战的想法是给你一个二进制文件，你需要弄清楚如何导致缓冲区溢出以使其打印出 flag 字符串。

via: https://jvns.ca/blog/2021/05/17/how-to-look-at-the-stack-in-gdb/

作者：Julia Evans 选题：lujun9972 译者：amwps290 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

使用 GNU 调试器来解决你的代码问题。

GNU 调试器常以它的命令 gdb 称呼它，它是一个交互式的控制台，可以帮助你浏览源代码、分析执行的内容，其本质上是对错误的应用程序中出现的问题进行逆向工程。

故障排除的麻烦在于它很复杂。GNU 调试器 并不是一个特别复杂的应用程序，但如果你不知道从哪里开始，甚至不知道何时和为何你可能需要求助于 GDB 来进行故障排除，那么它可能会让人不知所措。如果你一直使用 print、echo 或 printf 语句来调试你的代码，当你开始思考是不是还有更强大的东西时，那么本教程就是为你准备的。

有错误的代码

要开始使用 GDB，你需要一些代码。这里有一个用 C++ 写的示例应用程序（如果你一般不使用 C++ 编写程序也没关系，在所有语言中原理都是一样的），其来源于 猜谜游戏系列 中的一个例子。

#include <iostream>
#include <stdlib.h> //srand
#include <stdio.h>  //printf

using namespace std;

int main () {

srand (time(NULL));
int alpha = rand() % 8;
cout << "Hello world." << endl;
int beta = 2;

printf("alpha is set to is %s\n", alpha);
printf("kiwi is set to is %s\n", beta);

 return 0;
} // main

这个代码示例中有一个 bug，但它确实可以编译（至少在 GCC 5 的时候）。如果你熟悉 C++，你可能已经看到了，但这是一个简单的问题，可以帮助新的 GDB 用户了解调试过程。编译并运行它就可以看到错误：

$ g++ -o buggy example.cpp
$ ./buggy
Hello world.
Segmentation fault

排除段故障

从这个输出中，你可以推测变量 alpha 的设置是正确的，因为否则的话，你就不会看到它后面的那行代码执行。当然，这并不总是正确的，但这是一个很好的工作理论，如果你使用 printf 作为日志和调试器，基本上也会得出同样的结论。从这里，你可以假设 bug 在于成功打印的那一行之后的某行。然而，不清楚错误是在下一行还是在几行之后。

GNU 调试器是一个交互式的故障排除工具，所以你可以使用 gdb 命令来运行错误的代码。为了得到更好的结果，你应该从包含有调试符号的源代码中重新编译你的错误应用程序。首先，看看 GDB 在不重新编译的情况下能提供哪些信息：

$ gdb ./buggy
Reading symbols from ./buggy...done.
(gdb) start
Temporary breakpoint 1 at 0x400a44
Starting program: /home/seth/demo/buggy

Temporary breakpoint 1, 0x0000000000400a44 in main ()
(gdb)

当你以一个二进制可执行文件作为参数启动 GDB 时，GDB 会加载该应用程序，然后等待你的指令。因为这是你第一次在这个可执行文件上运行 GDB，所以尝试重复这个错误是有意义的，希望 GDB 能够提供进一步的见解。很直观，GDB 用来启动它所加载的应用程序的命令就是 start。默认情况下，GDB 内置了一个断点，所以当它遇到你的应用程序的 main 函数时，它会暂停执行。要让 GDB 继续执行，使用命令 continue：

(gdb) continue
Continuing.
Hello world.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff71c0c0b in vfprintf () from /lib64/libc.so.6
(gdb)

毫不意外：应用程序在打印 “Hello world” 后不久就崩溃了，但 GDB 可以提供崩溃发生时正在发生的函数调用。这有可能就足够你找到导致崩溃的 bug，但为了更好地了解 GDB 的功能和一般的调试过程，想象一下，如果问题还没有变得清晰，你想更深入地挖掘这段代码发生了什么。

用调试符号编译代码

要充分利用 GDB，你需要将调试符号编译到你的可执行文件中。你可以用 GCC 中的 -g 选项来生成这个符号：

$ g++ -g -o debuggy example.cpp
$ ./debuggy
Hello world.
Segmentation fault

将调试符号编译到可执行文件中的结果是得到一个大得多的文件，所以通常不会分发它们，以增加便利性。然而，如果你正在调试开源代码，那么用调试符号重新编译测试是有意义的：

$ ls -l *buggy* *cpp
-rw-r--r--    310 Feb 19 08:30 debug.cpp
-rwxr-xr-x  11624 Feb 19 10:27 buggy*
-rwxr-xr-x  22952 Feb 19 10:53 debuggy*

用 GDB 调试

加载新的可执行文件（本例中为 debuggy）以启动 GDB：

$ gdb ./debuggy
Reading symbols from ./debuggy...done.
(gdb) start
Temporary breakpoint 1 at 0x400a44
Starting program: /home/seth/demo/debuggy

Temporary breakpoint 1, 0x0000000000400a44 in main ()
(gdb)

如前所述，使用 start 命令进行：

(gdb) start
Temporary breakpoint 1 at 0x400a48: file debug.cpp, line 9.
Starting program: /home/sek/demo/debuggy

Temporary breakpoint 1, main () at debug.cpp:9
9       srand (time(NULL));
(gdb)

这一次，自动的 main 断点可以指明 GDB 暂停的行号和该行包含的代码。你可以用 continue 恢复正常操作，但你已经知道应用程序在完成之前就会崩溃，因此，你可以使用 next 关键字逐行步进检查你的代码：

(gdb) next
10  int alpha = rand() % 8;
(gdb) next
11  cout << "Hello world." << endl;
(gdb) next
Hello world.
12  int beta = 2;
(gdb) next
14      printf("alpha is set to is %s\n", alpha);
(gdb) next

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff71c0c0b in vfprintf () from /lib64/libc.so.6
(gdb)

从这个过程可以确认，崩溃不是发生在设置 beta 变量的时候，而是执行 printf 行的时候。这个 bug 在本文中已经暴露了好几次（破坏者：向 printf 提供了错误的数据类型），但暂时假设解决方案仍然不明确，需要进一步调查。

设置断点

一旦你的代码被加载到 GDB 中，你就可以向 GDB 询问到目前为止代码所产生的数据。要尝试数据自省，通过再次发出 start 命令来重新启动你的应用程序，然后进行到第 11 行。一个快速到达 11 行的简单方法是设置一个寻找特定行号的断点：

(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 2 at 0x400a48: file debug.cpp, line 9.
Starting program: /home/sek/demo/debuggy

Temporary breakpoint 2, main () at debug.cpp:9
9       srand (time(NULL));
(gdb) break 11
Breakpoint 3 at 0x400a74: file debug.cpp, line 11.

建立断点后，用 continue 继续执行：

(gdb) continue
Continuing.

Breakpoint 3, main () at debug.cpp:11
11      cout << "Hello world." << endl;
(gdb)

现在暂停在第 11 行，就在 alpha 变量被设置之后，以及 beta 被设置之前。

用 GDB 进行变量自省

要查看一个变量的值，使用 print 命令。在这个示例代码中，alpha 的值是随机的，所以你的实际结果可能与我的不同：

(gdb) print alpha
$1 = 3
(gdb)

当然，你无法看到一个尚未建立的变量的值：

(gdb) print beta
$2 = 0

使用流程控制

要继续进行，你可以步进代码行来到达将 beta 设置为一个值的位置：

(gdb) next
Hello world.
12  int beta = 2;
(gdb) next
14  printf("alpha is set to is %s\n", alpha);
(gdb) print beta
$3 = 2

另外，你也可以设置一个观察点，它就像断点一样，是一种控制 GDB 执行代码流程的方法。在这种情况下，你知道 beta 变量应该设置为 2，所以你可以设置一个观察点，当 beta 的值发生变化时提醒你：

(gdb) watch beta > 0
Hardware watchpoint 5: beta > 0
(gdb) continue
Continuing.

Breakpoint 3, main () at debug.cpp:11
11      cout << "Hello world." << endl;
(gdb) continue
Continuing.
Hello world.

Hardware watchpoint 5: beta > 0

Old value = false
New value = true
main () at debug.cpp:14
14      printf("alpha is set to is %s\n", alpha);
(gdb)

你可以用 next 手动步进完成代码的执行，或者你可以用断点、观察点和捕捉点来控制代码的执行。

用 GDB 分析数据

你可以以不同格式查看数据。例如，以八进制值查看 beta 的值：

(gdb) print /o beta
$4 = 02

要查看其在内存中的地址：

(gdb) print /o &beta
$5 = 0x2

你也可以看到一个变量的数据类型：

(gdb) whatis beta
type = int

用 GDB 解决错误

这种自省不仅能让你更好地了解什么代码正在执行，还能让你了解它是如何执行的。在这个例子中，对变量运行的 whatis 命令给了你一个线索，即你的 alpha 和 beta 变量是整数，这可能会唤起你对 printf 语法的记忆，使你意识到在你的 printf 语句中，你必须使用 %d 来代替 %s。做了这个改变，就可以让应用程序按预期运行，没有更明显的错误存在。

当代码编译后发现有 bug 存在时，特别令人沮丧，但最棘手的 bug 就是这样，如果它们很容易被发现，那它们就不是 bug 了。使用 GDB 是猎取并消除它们的一种方法。

下载我们的速查表

生活的真相就是这样，即使是最基本的编程，代码也会有 bug。并不是所有的错误都会导致应用程序无法运行（甚至无法编译），也不是所有的错误都是由错误的代码引起的。有时，bug 是基于一个特别有创意的用户所做的意外的选择组合而间歇性发生的。有时，程序员从他们自己的代码中使用的库中继承了 bug。无论原因是什么，bug 基本上无处不在，程序员的工作就是发现并消除它们。

GNU 调试器是一个寻找 bug 的有用工具。你可以用它做的事情比我在本文中演示的要多得多。你可以通过 GNU Info 阅读器来了解它的许多功能：

$ info gdb

无论你是刚开始学习 GDB 还是专业人员的，提醒一下你有哪些命令是可用的，以及这些命令的语法是什么，都是很有帮助的。

• 下载 GDB 速查表

via: https://opensource.com/article/21/3/debug-code-gdb

作者：Seth Kenlon 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

本文简短地对 Emacs 的调试工具 GUD 的特性进行了探索。

如果你是一个 C 或 C++ 开发者，你很可能已经使用过 GDB（GNU 调试器），毫无疑问，它是现今最强大、最无可匹敌的调试器之一。它唯一的缺点就是它基于命令行，虽然仍能提供许多强大的功能，但有时也会具有一些局限性。这也就是为什么聪明的人们开始追求整合了编辑器和调试器的 图形化 GUI 集成开发环境 Integrated Development Environment 。仍有些开发者坚信使用鼠标会降低工作效率，在 GUI 上用鼠标点～点～点～是来自恶魔的诱惑。

因为 Emacs 是现今最酷的文本编辑器之一，我将为你展示如何在不碰鼠标且不离开 Emacs 的情况下，实现写代码、编译代码、调试代码的过程。

GUD（LCTT 译注：全称 大统一调试器 Grand Unified Debugger ，鉴于其缩写形式更为人熟知，以下全文将使用缩写替代此全称）是 Emacs 下的一个 模式 mode ，用于在 Emacs 中运行 GDB。它向 GDB 提供了 Emacs 的所有特性，使用户无需离开编辑器就可以对代码进行调试。

使用 GUD 的前期准备

如果你正在使用一个 Linux 机器，很可能你已经安装了 GDB 和 gcc，接下来就是要确保已经安装了 Emacs。以下的内容我将假设读者熟悉 GDB 并且至少用它做过基本的调试。如果你未曾接触过 GDB，你可以做个快速入门，这些资料在网上随处可得。

对于那些 Emacs 新手，我将向你介绍一些基本术语。纵览整篇文章，你将看到诸如 C-c M-x 等快捷键。此处 C 代表 Ctrl 键，M 代表 Alt 键。C-c 代表 Ctrl 键和 c 键被同时按下。如果你看到 C-c c，它代表同时按下 Ctrl 键和 c 键，释放后紧接着按下 c 键。在 Emacs 中，编辑文本的主要区域被称为 主缓冲区 main buffer ，而在 Emacs 窗口下方用于输入命令的区域被称为 迷你缓冲区 mini buffer 。

启动 Emacs，并按下 C-x C-f 来创建一个新文件。Emacs 将提示你输入一个文件名，此处让我们将文件命名为 buggyFactorial.cpp。一旦文件打开，输入如下代码：

#include<iostream>
#include <assert.h>

int factorial(int num) {
  int product = 1;
  while(num--) {
    product *= num;
  }
  return product;
}
int main() {
  int result = factorial(5);
  assert(result == 120);
}

使用 C-x C-s 快捷键保存文件。文件保存完毕，是时候进行编译了。按下 M-x，在弹出的 提示符 prompt 后输入 compile 并点击回车。然后在提示符后，将内容替换为 g++ -g buggyFactorial.cpp 并再次点击回车。

这将在 Emacs 中开启另一个缓冲区，显示编译的状态。如果你的代码输入没有错误，你将预期得到如图 2 所示的缓冲区。

要想隐藏编译缓冲区，首先确保你的光标在编译缓冲区中（你可以不使用鼠标，而是通过 C-x o 快捷键将光标从一个缓冲区移动到另一个），然后按下 C-x 0。下一步就是运行代码，并观察是否运行良好。按下 M-! 快捷键并在迷你缓冲区的提示符后面输入 ./a.out。

你可以看到迷你缓冲区中显示断言失败。很明显代码中有错误，因为 5 的阶乘是 120。那么让我们现在开始调试吧。

使用 GUD 调式代码

现在，我们的代码已经编译完成，是时候看看到底哪里出错了。按下 M-x 快捷键并在提示符后输入 gdb。在接下来的提示符后，输入 gdb -i=mi a.out。如果一切顺利，GDB 会在 Emacs 缓冲区中启动，你会看到如图 4 所示的窗口。

在 gdb 提示符后，输入 break main 来设置断点，并输入 r 来运行程序。程序会开始运行并停在 main() 函数处。

一旦 GDB 到达了 main 处设置的断点，就会弹出一个新的缓冲区显示你正在调试的代码。注意左侧的红点，正是你设置断点的位置，同时会有一个小的标志提示你当前代码运行到了哪一行。当前，该标志就在断点处（如图 5）。

为了调试 factorial 函数，我们需要单步运行。想要达到此目的，你可以在 GBD 提示符使用 GDB 命令 step，或者使用 Emacs 快捷键 C-c C-s。还有其它一些快捷键，但我更喜欢 GDB 命令。因此我将在本文的后续部分使用它们。

单步运行时让我们注意一下局部变量中的阶乘值。参考图 6 来设置在 Emacs 帧中显示局部变量值。

在 GDB 提示符中进行单步运行并观察局部变量值的变化。在循环的第一次迭代中，我们发现了一个问题。此处乘法的结果应该是 5 而不是 4。

本文到这里也差不多结束了，读者可以自行探索发现 GUD 模式这片新大陆。GDB 中的所有命令都可以在 GUD 模式中运行。我将此代码的修复留给读者作为一个练习。看看你在调试的过程中，可以做哪一些定制化，来使你的工作流更加简单和高效。

via: https://opensourceforu.com/2019/09/debugging-in-emacs-the-grand-unified-debugger/

作者：Vineeth Kartha 选题：lujun9972 译者：cycoe 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

了解如何使用 gdb 的一些鲜为人知的功能来检查和修复代码。

GNU 调试器（gdb）是一种宝贵的工具，可用于在开发程序时检查正在运行的进程并解决问题。

你可以在特定位置（按函数名称、行号等）设置断点、启用和禁用这些断点、显示和更改变量值，并执行所有调试器希望执行的所有标准操作。但是它还有许多其它你可能没有尝试过的功能。这里有五个你可以尝试一下。

条件断点

设置断点是学习使用 GNU 调试器的第一步。程序在达到断点时停止，你可以运行 gdb 的命令对其进行检查或更改变量，然后再允许该程序继续运行。

例如，你可能知道一个经常调用的函数有时会崩溃，但仅当它获得某个参数值时才会崩溃。你可以在该函数的开始处设置一个断点并运行程序。每次碰到该断点时都会显示函数参数，并且如果未提供触发崩溃的参数值，则可以继续操作，直到再次调用该函数为止。当这个惹了麻烦的参数触发崩溃时，你可以单步执行代码以查看问题所在。

(gdb) break sometimes_crashes
Breakpoint 1 at 0x40110e: file prog.c, line 5.
(gdb) run
[...]
Breakpoint 1, sometimes_crashes (f=0x7fffffffd1bc) at prog.c:5
5      fprintf(stderr,
(gdb) continue
Breakpoint 1, sometimes_crashes (f=0x7fffffffd1bc) at prog.c:5
5      fprintf(stderr,
(gdb) continue

为了使此方法更具可重复性，你可以在你感兴趣的特定调用之前计算该函数被调用的次数，并在该断点处设置一个计数器（例如，continue 30 以使其在接下来的 29 次到达该断点时忽略它）。

但是断点真正强大的地方在于它们在运行时评估表达式的能力，这使你可以自动化这种测试。

break [LOCATION] if CONDITION

(gdb) break sometimes_crashes if !f
Breakpoint 1 at 0x401132: file prog.c, line 5.
(gdb) run
[...]
Breakpoint 1, sometimes_crashes (f=0x0) at prog.c:5
5      fprintf(stderr,
(gdb)

条件断点使你不必让 gdb 每次调用该函数时都去问你要做什么，而是让条件断点仅在特定表达式的值为 true 时才使 gdb 停止在该位置。如果执行到达条件断点的位置，但表达式的计算结果为 false，调试器会自动使程序继续运行，而无需询问用户该怎么做。

断点命令

GNU 调试器中断点的一个甚至更复杂的功能是能够编写对到达断点的响应的脚本。断点命令使你可以编写一系列 GNU 调试器命令，以在到达该断点时运行。

我们可以使用它来规避在 sometimes_crashes 函数中我们已知的错误，并在它提供空指针时使其无害地从该函数返回。

我们可以使用 silent 作为第一行，以更好地控制输出。否则，每次命中断点时，即使在运行断点命令之前，也会显示堆栈帧。

(gdb) break sometimes_crashes
Breakpoint 1 at 0x401132: file prog.c, line 5.
(gdb) commands 1
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>silent
>if !f
 >frame
 >printf "Skipping call\n"
 >return 0
 >continue
 >end
>printf "Continuing\n"
>continue
>end
(gdb) run
Starting program: /home/twaugh/Documents/GDB/prog
warning: Loadable section ".note.gnu.property" outside of ELF segments
Continuing
Continuing
Continuing
#0  sometimes_crashes (f=0x0) at prog.c:5
5      fprintf(stderr,
Skipping call
[Inferior 1 (process 9373) exited normally]
(gdb)

转储二进制内存

GNU 调试器内置支持使用 x 命令以各种格式检查内存，包括八进制、十六进制等。但是我喜欢并排看到两种格式：左侧为十六进制字节，右侧为相同字节表示的 ASCII 字符。

当我想逐字节查看文件的内容时，经常使用 hexdump -C（hexdump 来自 util-linux 软件包）。这是 gdb 的 x 命令显示的十六进制字节：

(gdb) x/33xb mydata
0x404040 <mydata>   :    0x02    0x01    0x00    0x02    0x00    0x00    0x00    0x01
0x404048 <mydata+8> :    0x01    0x47    0x00    0x12    0x61    0x74    0x74    0x72
0x404050 <mydata+16>:    0x69    0x62    0x75    0x74    0x65    0x73    0x2d    0x63
0x404058 <mydata+24>:    0x68    0x61    0x72    0x73    0x65    0x75    0x00    0x05
0x404060 <mydata+32>:    0x00

如果你想让 gdb 像 hexdump 一样显示内存怎么办？这是可以的，实际上，你可以将这种方法用于你喜欢的任何格式。

通过使用 dump 命令以将字节存储在文件中，结合 shell 命令以在文件上运行 hexdump 以及define 命令，我们可以创建自己的新的 hexdump 命令来使用 hexdump 显示内存内容。

(gdb) define hexdump
Type commands for definition of "hexdump".
End with a line saying just "end".
>dump binary memory /tmp/dump.bin $arg0 $arg0+$arg1
>shell hexdump -C /tmp/dump.bin
>end

这些命令甚至可以放在 ~/.gdbinit 文件中，以永久定义 hexdump 命令。以下是它运行的例子：

(gdb) hexdump mydata sizeof(mydata)
00000000  02 01 00 02 00 00 00 01  01 47 00 12 61 74 74 72  |.........G..attr|
00000010  69 62 75 74 65 73 2d 63  68 61 72 73 65 75 00 05  |ibutes-charseu..|
00000020  00                                                |.|
00000021

行内反汇编

有时你想更多地了解导致崩溃的原因，而源代码还不够。你想查看在 CPU 指令级别发生了什么。

disassemble 命令可让你查看实现函数的 CPU 指令。但是有时输出可能很难跟踪。通常，我想查看与该函数源代码的特定部分相对应的指令。为此，请使用 /s 修饰符在反汇编中包括源代码行。

(gdb) disassemble/s main
Dump of assembler code for function main:
prog.c:
11    {
   0x0000000000401158 <+0>:    push   %rbp
   0x0000000000401159 <+1>:    mov      %rsp,%rbp
   0x000000000040115c <+4>:    sub      $0x10,%rsp

12      int n = 0;
   0x0000000000401160 <+8>:    movl   $0x0,-0x4(%rbp)

13      sometimes_crashes(&n);
   0x0000000000401167 <+15>:    lea     -0x4(%rbp),%rax
   0x000000000040116b <+19>:    mov     %rax,%rdi
   0x000000000040116e <+22>:    callq  0x401126 <sometimes_crashes>
[...snipped...]

这里，用 info 寄存器查看所有 CPU 寄存器的当前值，以及用如 stepi 这样命令一次执行一条指令，可以使你对程序有了更详细的了解。

反向调试

有时，你希望自己可以逆转时间。想象一下，你已经达到了变量的监视点。监视点像是一个断点，但不是在程序中的某个位置设置，而是在表达式上设置（使用 watch 命令）。每当表达式的值更改时，执行就会停止，并且调试器将获得控制权。

想象一下你已经达到了这个监视点，并且由该变量使用的内存已更改了值。事实证明，这可能是由更早发生的事情引起的。例如，内存已释放，现在正在重新使用。但是它是何时何地被释放的呢？

GNU 调试器甚至可以解决此问题，因为你可以反向运行程序！

它通过在每个步骤中仔细记录程序的状态来实现此目的，以便可以恢复以前记录的状态，从而产生时间倒流的错觉。

要启用此状态记录，请使用 target record-full 命令。然后，你可以使用一些听起来不太可行的命令，例如：

• reverse-step，倒退到上一个源代码行
• *reverse-next，它倒退到上一个源代码行，向后跳过函数调用
• reverse-finish，倒退到当前函数即将被调用的时刻
• reverse-continue，它返回到程序中的先前状态，该状态将（现在）触发断点（或其他导致断点停止的状态）

这是运行中的反向调试的示例：

(gdb) b main
Breakpoint 1 at 0x401160: file prog.c, line 12.
(gdb) r
Starting program: /home/twaugh/Documents/GDB/prog
[...]

Breakpoint 1, main () at prog.c:12
12      int n = 0;
(gdb) target record-full
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000401154 in sometimes_crashes (f=0x0) at prog.c:7
7      return *f;
(gdb) reverse-finish
Run back to call of #0  0x0000000000401154 in sometimes_crashes (f=0x0)
        at prog.c:7
0x0000000000401190 in main () at prog.c:16
16      sometimes_crashes(0);

这些只是 GNU 调试器可以做的一些有用的事情。还有更多有待发现。你最喜欢 gdb 的哪个隐藏的、鲜为人知或令人吃惊的功能？请在评论中分享。

via: https://opensource.com/article/19/9/tips-gnu-debugger

作者：Tim Waugh 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出