标签 gdb 下的文章

Caffeinated 6.828：实验工具指南

Csail.mit 发布于 2018-11-25
另请参阅: 技术,gdb, '6.828'
评论

熟悉你的环境对高效率的开发和调试来说是至关重要的。本文将为你简单概述一下 JOS 环境和非常有用的 GDB 和 QEMU 命令。话虽如此，但你仍然应该去阅读 GDB 和 QEMU 手册，来理解这些强大的工具如何使用。

调试小贴士

内核

GDB 是你的朋友。使用 qemu-gdb target（或它的变体 qemu-gdb-nox）使 QEMU 等待 GDB 去绑定。下面在调试内核时用到的一些命令，可以去查看 GDB 的资料。

如果你遭遇意外的中断、异常、或三重故障，你可以使用 -d 参数要求 QEMU 去产生一个详细的中断日志。

调试虚拟内存问题时，尝试 QEMU 的监视命令 info mem（提供内存高级概述）或 info pg（提供更多细节内容）。注意，这些命令仅显示当前页表。

（在实验 4 以后）去调试多个 CPU 时，使用 GDB 的线程相关命令，比如 thread 和 info threads。

用户环境（在实验 3 以后）

GDB 也可以去调试用户环境，但是有些事情需要注意，因为 GDB 无法区分开多个用户环境或区分开用户环境与内核环境。

你可以使用 make run-name（或编辑 kern/init.c 目录）来指定 JOS 启动的用户环境，为使 QEMU 等待 GDB 去绑定，使用 run-name-gdb 的变体。

你可以符号化调试用户代码，就像调试内核代码一样，但是你要告诉 GDB，哪个符号表用到符号文件命令上，因为它一次仅能够使用一个符号表。提供的 .gdbinit 用于加载内核符号表 obj/kern/kernel。对于一个用户环境，这个符号表在它的 ELF 二进制文件中，因此你可以使用 symbol-file obj/user/name 去加载它。不要从任何 .o 文件中加载符号，因为它们不会被链接器迁移进去（库是静态链接进 JOS 用户二进制文件中的，因此这些符号已经包含在每个用户二进制文件中了）。确保你得到了正确的用户二进制文件；在不同的二进制文件中，库函数被链接为不同的 EIP，而 GDB 并不知道更多的内容！

（在实验 4 以后）因为 GDB 绑定了整个虚拟机，所以它可以将时钟中断看作为一种控制转移。这使得从底层上不可能实现步进用户代码，因为一个时钟中断无形中保证了片刻之后虚拟机可以再次运行。因此可以使用 stepi 命令，因为它阻止了中断，但它仅可以步进一个汇编指令。断点一般来说可以正常工作，但要注意，因为你可能在不同的环境（完全不同的一个二进制文件）上遇到同一个 EIP。

参考

JOS makefile

JOS 的 GNUmakefile 包含了在各种方式中运行的 JOS 的许多假目标。所有这些目标都配置 QEMU 去监听 GDB 连接（*-gdb 目标也等待这个连接）。要在运行中的 QEMU 上启动它，只需要在你的实验目录中简单地运行 gdb 即可。我们提供了一个 .gdbinit 文件，它可以在 QEMU 中自动指向到 GDB、加载内核符号文件、以及在 16 位和 32 位模式之间切换。退出 GDB 将关闭 QEMU。

make qemu

在一个新窗口中构建所有的东西并使用 VGA 控制台和你的终端中的串行控制台启动 QEMU。想退出时，既可以关闭 VGA 窗口，也可以在你的终端中按 Ctrl-c 或 Ctrl-a x。

make qemu-nox

和 make qemu 一样，但仅使用串行控制台来运行。想退出时，按下 Ctrl-a x。这种方式在通过 SSH 拨号连接到 Athena 上时非常有用，因为 VGA 窗口会占用许多带宽。

make qemu-gdb

和 make qemu 一样，但它与任意时间被动接受 GDB 不同，而是暂停第一个机器指令并等待一个 GDB 连接。

make qemu-nox-gdb

它是 qemu-nox 和 qemu-gdb 目标的组合。

make run-nam

（在实验 3 以后）运行用户程序 name。例如，make run-hello 运行 user/hello.c。

make run-name-nox,run-name-gdb, run-name-gdb-nox

（在实验 3 以后）与 qemu 目标变量对应的 run-name 的变体。

makefile 也接受几个非常有用的变量：

make V=1 …

详细模式。输出正在运行的每个命令，包括参数。

make V=1 grade

在评级测试失败后停止，并将 QEMU 的输出放入 jos.out 文件中以备检查。

make QEMUEXTRA=' _args_ ' …

指定传递给 QEMU 的额外参数。

JOS obj/

在构建 JOS 时，makefile 也产生一些额外的输出文件，这些文件在调试时非常有用：

obj/boot/boot.asm、obj/kern/kernel.asm、obj/user/hello.asm、等等。

引导加载器、内核、和用户程序的汇编代码列表。

obj/kern/kernel.sym、obj/user/hello.sym、等等。

内核和用户程序的符号表。

obj/boot/boot.out、obj/kern/kernel、obj/user/hello、等等。

内核和用户程序链接的 ELF 镜像。它们包含了 GDB 用到的符号信息。

GDB

完整的 GDB 命令指南请查看 GDB 手册。下面是一些在 6.828 课程中非常有用的命令，它们中的一些在操作系统开发之外的领域几乎用不到。

Ctrl-c

在当前指令处停止机器并打断进入到 GDB。如果 QEMU 有多个虚拟的 CPU，所有的 CPU 都会停止。

c（或 continue）

继续运行，直到下一个断点或 Ctrl-c。

si（或 stepi）

运行一个机器指令。

b function 或 b file:line（或 breakpoint）

在给定的函数或行上设置一个断点。

b * addr（或 breakpoint）

在 EIP 的 addr 处设置一个断点。

set print pretty

启用数组和结构的美化输出。

info registers

输出通用寄存器 eip、eflags、和段选择器。更多更全的机器寄存器状态转储，查看 QEMU 自己的 info registers 命令。

x/ N x addr

以十六进制显示虚拟地址 addr 处开始的 N 个词的转储。如果 N 省略，默认为 1。addr 可以是任何表达式。

x/ N i addr

显示从 addr 处开始的 N 个汇编指令。使用 $eip 作为 addr 将显示当前指令指针寄存器中的指令。

symbol-file file

（在实验 3 以后）切换到符号文件 file 上。当 GDB 绑定到 QEMU 后，它并不是虚拟机中进程边界内的一部分，因此我们要去告诉它去使用哪个符号。默认情况下，我们配置 GDB 去使用内核符号文件 obj/kern/kernel。如果机器正在运行用户代码，比如是 hello.c，你就需要使用 symbol-file obj/user/hello 去切换到 hello 的符号文件。

QEMU 将每个虚拟 CPU 表示为 GDB 中的一个线程，因此你可以使用 GDB 中所有的线程相关的命令去查看或维护 QEMU 的虚拟 CPU。

thread n

GDB 在一个时刻只关注于一个线程（即：CPU）。这个命令将关注的线程切换到 n，n 是从 0 开始编号的。

info threads

列出所有的线程（即：CPU），包括它们的状态（活动还是停止）和它们在什么函数中。

QEMU

QEMU 包含一个内置的监视器，它能够有效地检查和修改机器状态。想进入到监视器中，在运行 QEMU 的终端中按入 Ctrl-a c 即可。再次按下 Ctrl-a c 将切换回串行控制台。

监视器命令的完整参考资料，请查看 QEMU 手册。下面是 6.828 课程中用到的一些有用的命令：

xp/ N x paddr

显示从物理地址 paddr 处开始的 N 个词的十六进制转储。如果 N 省略，默认为 1。这是 GDB 的 x 命令模拟的物理内存。

info registers

显示机器内部寄存器状态的一个完整转储。实践中，对于段选择器，这将包含机器的隐藏段状态和局部、全局、和中断描述符表加任务状态寄存器。隐藏状态是在加载段选择器后，虚拟的 CPU 从 GDT/LDT 中读取的信息。下面是实验 1 中 JOS 内核处于运行中时的 CS 信息和每个字段的含义：

CS =0008 10000000 ffffffff 10cf9a00 DPL=0 CS32 [-R-]

CS =0008

代码选择器可见部分。我们使用段 0x8。这也告诉我们参考全局描述符表（0x8&4=0），并且我们的 CPL（当前权限级别）是 0x8&3=0。

10000000

这是段基址。线性地址 = 逻辑地址 + 0x10000000。

ffffffff

这是段限制。访问线性地址 0xffffffff 以上将返回段违规异常。

10cf9a00

段的原始标志，QEMU 将在接下来的几个字段中解码这些对我们有用的标志。

DPL=0

段的权限级别。一旦代码以权限 0 运行，它将就能够加载这个段。

CS32

这是一个 32 位代码段。对于数据段（不要与 DS 寄存器混淆了），另外的值还包括 DS，而对于本地描述符表是 LDT。

[-R-]

这个段是只读的。

info mem

（在实验 2 以后）显示映射的虚拟内存和权限。比如：

ef7c0000-ef800000 00040000 urw
efbf8000-efc00000 00008000 -rw

这告诉我们从 0xef7c0000 到 0xef800000 的 0x00040000 字节的内存被映射为读取/写入/用户可访问，而映射在 0xefbf8000 到 0xefc00000 之间的内存权限是读取/写入，但是仅限于内核可访问。

info pg

（在实验 2 以后）显示当前页表结构。它的输出类似于 info mem，但与页目录条目和页表条目是有区别的，并且为每个条目给了单独的权限。重复的 PTE 和整个页表被折叠为一个单行。例如：

VPN range     Entry         Flags        Physical page
[00000-003ff]  PDE[000]     -------UWP
  [00200-00233]  PTE[200-233] -------U-P 00380 0037e 0037d 0037c 0037b 0037a ..
[00800-00bff]  PDE[002]     ----A--UWP
  [00800-00801]  PTE[000-001] ----A--U-P 0034b 00349
  [00802-00802]  PTE[002]     -------U-P 00348

这里各自显示了两个页目录条目、虚拟地址范围 0x00000000 到 0x003fffff 以及 0x00800000 到 0x00bfffff。所有的 PDE 都存在于内存中、可写入、并且用户可访问，而第二个 PDE 也是可访问的。这些页表中的第二个映射了三个页、虚拟地址范围 0x00800000 到 0x00802fff，其中前两个页是存在于内存中的、可写入、并且用户可访问的，而第三个仅存在于内存中，并且用户可访问。这些 PTE 的第一个条目映射在物理页 0x34b 处。

QEMU 也有一些非常有用的命令行参数，使用 QEMUEXTRA 变量可以将参数传递给 JOS 的 makefile。

make QEMUEXTRA='-d int' ...

记录所有的中断和一个完整的寄存器转储到 qemu.log 文件中。你可以忽略前两个日志条目、“SMM: enter” 和 “SMM: after RMS”，因为这些是在进入引导加载器之前生成的。在这之后的日志条目看起来像下面这样：

     4: v=30 e=0000 i=1 cpl=3 IP=001b:00800e2e pc=00800e2e SP=0023:eebfdf28 EAX=00000005
EAX=00000005 EBX=00001002 ECX=00200000 EDX=00000000
ESI=00000805 EDI=00200000 EBP=eebfdf60 ESP=eebfdf28
...

第一行描述了中断。4: 只是一个日志记录计数器。v 提供了十六进程的向量号。e 提供了错误代码。i=1 表示它是由一个 int 指令（相对一个硬件产生的中断而言）产生的。剩下的行的意思很明显。对于一个寄存器转储而言，接下来看到的就是寄存器信息。

注意：如果你运行的是一个 0.15 版本之前的 QEMU，日志将写入到 /tmp 目录，而不是当前目录下。

via: https://pdos.csail.mit.edu/6.828/2018/labguide.html

作者：csail.mit 选题：lujun9972 译者：qhwdw 校对：wxy

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

gdb 如何调用函数？

Julia Evans 发布于 2018-04-29
另请参阅: 软件开发,调试, gdb
评论

（之前的 gdb 系列文章：gdb 如何工作（2016）和三步上手 gdb（2014））

在这周，我发现我可以从 gdb 上调用 C 函数。这看起来很酷，因为在过去我认为 gdb 最多只是一个只读调试工具。

我对 gdb 能够调用函数感到很吃惊。正如往常所做的那样，我在 Twitter 上询问这是如何工作的。我得到了大量的有用答案。我最喜欢的答案是 Evan Klitzke 的示例 C 代码，它展示了 gdb 如何调用函数。代码能够运行，这很令人激动！

我（通过一些跟踪和实验）认为那个示例 C 代码和 gdb 实际上如何调用函数不同。因此，在这篇文章中，我将会阐述 gdb 是如何调用函数的，以及我是如何知道的。

关于 gdb 如何调用函数，还有许多我不知道的事情，并且，在这儿我写的内容有可能是错误的。

从 gdb 中调用 C 函数意味着什么？

在开始讲解这是如何工作之前，我先快速的谈论一下我是如何发现这件令人惊讶的事情的。

假如，你已经在运行一个 C 程序（目标程序）。你可以运行程序中的一个函数，只需要像下面这样做：

暂停程序（因为它已经在运行中）
找到你想调用的函数的地址（使用符号表）
使程序（目标程序）跳转到那个地址
当函数返回时，恢复之前的指令指针和寄存器

通过符号表来找到想要调用的函数的地址非常容易。下面是一段非常简单但能够工作的代码，我在 Linux 上使用这段代码作为例子来讲解如何找到地址。这段代码使用 elf crate。如果我想找到 PID 为 2345 的进程中的 foo 函数的地址，那么我可以运行 elf_symbol_value("/proc/2345/exe", "foo")。

fn elf_symbol_value(file_name: &str, symbol_name: &str) -> Result<u64, Box<std::error::Error>> {
    // 打开 ELF 文件 
    let file = elf::File::open_path(file_name).ok().ok_or("parse error")?;
    // 在所有的段 & 符号中循环，直到找到正确的那个
    let sections = &file.sections;
    for s in sections {
        for sym in file.get_symbols(&s).ok().ok_or("parse error")? {
            if sym.name == symbol_name {
                return Ok(sym.value);
            }
        }
    }
    None.ok_or("No symbol found")?
}

这并不能够真的发挥作用，你还需要找到文件的内存映射，并将符号偏移量加到文件映射的起始位置。找到内存映射并不困难，它位于 /proc/PID/maps 中。

总之，找到想要调用的函数地址对我来说很直接，但是其余部分（改变指令指针，恢复寄存器等）看起来就不这么明显了。

你不能仅仅进行跳转

我已经说过，你不能够仅仅找到你想要运行的那个函数地址，然后跳转到那儿。我在 gdb 中尝试过那样做（jump foo），然后程序出现了段错误。毫无意义。

如何从 gdb 中调用 C 函数

首先，这是可能的。我写了一个非常简洁的 C 程序，它所做的事只有 sleep 1000 秒，把这个文件命名为 test.c ：

#include <unistd.h>

int foo() {
    return 3;
}
int main() {
    sleep(1000);
}

接下来，编译并运行它：

$ gcc -o test  test.c
$ ./test

最后，我们使用 gdb 来跟踪 test 这一程序：

$ sudo gdb -p $(pgrep -f test)
(gdb) p foo()
$1 = 3
(gdb) quit

我运行 p foo() 然后它运行了这个函数！这非常有趣。

这有什么用？

下面是一些可能的用途：

它使得你可以把 gdb 当成一个 C 应答式程序（REPL），这很有趣，我想对开发也会有用
在 gdb 中进行调试的时候展示/浏览复杂数据结构的功能函数（感谢 @invalidop）
在进程运行时设置一个任意的名字空间（我的同事 nelhage 对此非常惊讶）
可能还有许多我所不知道的用途

它是如何工作的

当我在 Twitter 上询问从 gdb 中调用函数是如何工作的时，我得到了大量有用的回答。许多答案是“你从符号表中得到了函数的地址”，但这并不是完整的答案。

有个人告诉了我两篇关于 gdb 如何工作的系列文章：原生调试：第一部分，原生调试：第二部分。第一部分讲述了 gdb 是如何调用函数的（指出了 gdb 实际上完成这件事并不简单，但是我将会尽力）。

步骤列举如下：

停止进程
创建一个新的栈框（远离真实栈）
保存所有寄存器
设置你想要调用的函数的寄存器参数
设置栈指针指向新的栈框 stack frame
在内存中某个位置放置一条陷阱指令
为陷阱指令设置返回地址
设置指令寄存器的值为你想要调用的函数地址
再次运行进程！

（LCTT 译注：如果将这个调用的函数看成一个单独的线程，gdb 实际上所做的事情就是一个简单的线程上下文切换）

我不知道 gdb 是如何完成这些所有事情的，但是今天晚上，我学到了这些所有事情中的其中几件。

创建一个栈框

如果你想要运行一个 C 函数，那么你需要一个栈来存储变量。你肯定不想继续使用当前的栈。准确来说，在 gdb 调用函数之前（通过设置函数指针并跳转），它需要设置栈指针到某个地方。

这儿是 Twitter 上一些关于它如何工作的猜测：

我认为它在当前栈的栈顶上构造了一个新的栈框来进行调用！

以及

你确定是这样吗？它应该是分配一个伪栈，然后临时将 sp （栈指针寄存器）的值改为那个栈的地址。你可以试一试，你可以在那儿设置一个断点，然后看一看栈指针寄存器的值，它是否和当前程序寄存器的值相近？

我通过 gdb 做了一个试验：

(gdb) p $rsp
$7 = (void *) 0x7ffea3d0bca8
(gdb) break foo
Breakpoint 1 at 0x40052a
(gdb) p foo()
Breakpoint 1, 0x000000000040052a in foo ()
(gdb) p $rsp
$8 = (void *) 0x7ffea3d0bc00

这看起来符合“gdb 在当前栈的栈顶构造了一个新的栈框”这一理论。因为栈指针（$rsp）从 0x7ffea3d0bca8 变成了 0x7ffea3d0bc00 —— 栈指针从高地址往低地址长。所以 0x7ffea3d0bca8 在 0x7ffea3d0bc00 的后面。真是有趣！

所以，看起来 gdb 只是在当前栈所在位置创建了一个新的栈框。这令我很惊讶！

改变指令指针

让我们来看一看 gdb 是如何改变指令指针的！

(gdb) p $rip
$1 = (void (*)()) 0x7fae7d29a2f0 <__nanosleep_nocancel+7>
(gdb) b foo
Breakpoint 1 at 0x40052a
(gdb) p foo()
Breakpoint 1, 0x000000000040052a in foo ()
(gdb) p $rip
$3 = (void (*)()) 0x40052a <foo+4>

的确是！指令指针从 0x7fae7d29a2f0 变为了 0x40052a（foo 函数的地址）。

我盯着输出看了很久，但仍然不理解它是如何改变指令指针的，但这并不影响什么。

如何设置断点

上面我写到 break foo 。我跟踪 gdb 运行程序的过程，但是没有任何发现。

下面是 gdb 用来设置断点的一些系统调用。它们非常简单。它把一条指令用 cc 代替了（这告诉我们 int3 意味着 send SIGTRAP https://defuse.ca/online-x86-assembler.html），并且一旦程序被打断了，它就把指令恢复为原先的样子。

我在函数 foo 那儿设置了一个断点，地址为 0x400528 。

PTRACE_POKEDATA 展示了 gdb 如何改变正在运行的程序。

// 改变 0x400528 处的指令
25622 ptrace(PTRACE_PEEKTEXT, 25618, 0x400528, [0x5d00000003b8e589]) = 0
25622 ptrace(PTRACE_POKEDATA, 25618, 0x400528, 0x5d00000003cce589) = 0
// 开始运行程序
25622 ptrace(PTRACE_CONT, 25618, 0x1, SIG_0) = 0
// 当到达断点时获取一个信号
25622 ptrace(PTRACE_GETSIGINFO, 25618, NULL, {si_signo=SIGTRAP, si_code=SI_KERNEL, si_value={int=-1447215360, ptr=0x7ffda9bd3f00}}) = 0
// 将 0x400528 处的指令更改为之前的样子
25622 ptrace(PTRACE_PEEKTEXT, 25618, 0x400528, [0x5d00000003cce589]) = 0
25622 ptrace(PTRACE_POKEDATA, 25618, 0x400528, 0x5d00000003b8e589) = 0

在某处放置一条陷阱指令

当 gdb 运行一个函数的时候，它也会在某个地方放置一条陷阱指令。这是其中一条。它基本上是用 cc 来替换一条指令（int3）。

5908  ptrace(PTRACE_PEEKTEXT, 5810, 0x7f6fa7c0b260, [0x48f389fd89485355]) = 0
5908  ptrace(PTRACE_PEEKTEXT, 5810, 0x7f6fa7c0b260, [0x48f389fd89485355]) = 0
5908 ptrace(PTRACE_POKEDATA, 5810, 0x7f6fa7c0b260, 0x48f389fd894853cc) = 0

0x7f6fa7c0b260 是什么？我查看了进程的内存映射，发现它位于 /lib/x86_64-linux-gnu/libc-2.23.so 中的某个位置。这很奇怪，为什么 gdb 将陷阱指令放在 libc 中？

让我们看一看里面的函数是什么，它是 __libc_siglongjmp 。其他 gdb 放置陷阱指令的地方的函数是 __longjmp 、___longjmp_chk 、dl_main 和 _dl_close_worker 。

为什么？我不知道！也许出于某种原因，当函数 foo() 返回时，它调用 longjmp ，从而 gdb 能够进行返回控制。我不确定。

gdb 如何调用函数是很复杂的！

我将要在这儿停止了（现在已经凌晨 1 点），但是我知道的多一些了！

看起来“gdb 如何调用函数”这一问题的答案并不简单。我发现这很有趣并且努力找出其中一些答案，希望你也能够找到。

我依旧有很多未回答的问题，关于 gdb 是如何完成这些所有事的，但是可以了。我不需要真的知道关于 gdb 是如何工作的所有细节，但是我很开心，我有了一些进一步的理解。

via: https://jvns.ca/blog/2018/01/04/how-does-gdb-call-functions/

作者：Julia Evans 译者：ucasFL 校对：wxy

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

gdb 如何工作？

Julia Evans 发布于 2018-03-29
另请参阅: 软件开发,调试, gdb
评论

大家好！今天，我开始进行我的 ruby 堆栈跟踪项目，我发觉我现在了解了一些关于 gdb 内部如何工作的内容。

最近，我使用 gdb 来查看我的 Ruby 程序，所以，我们将对一个 Ruby 程序运行 gdb 。它实际上就是一个 Ruby 解释器。首先，我们需要打印出一个全局变量的地址：ruby_current_thread。

获取全局变量

下面展示了如何获取全局变量 ruby_current_thread 的地址：

$ sudo gdb -p 2983
(gdb) p & ruby_current_thread
$2 = (rb_thread_t **) 0x5598a9a8f7f0 <ruby_current_thread>

变量能够位于的地方有堆 heap 、栈 stack 或者程序的文本段 text 。全局变量是程序的一部分。某种程度上，你可以把它们想象成是在编译的时候分配的。因此，我们可以很容易的找出全局变量的地址。让我们来看看，gdb 是如何找出 0x5598a9a87f0 这个地址的。

我们可以通过查看位于 /proc 目录下一个叫做 /proc/$pid/maps 的文件，来找到这个变量所位于的大致区域。

$ sudo cat /proc/2983/maps | grep bin/ruby
5598a9605000-5598a9886000 r-xp 00000000 00:32 323508                     /home/bork/.rbenv/versions/2.1.6/bin/ruby
5598a9a86000-5598a9a8b000 r--p 00281000 00:32 323508                     /home/bork/.rbenv/versions/2.1.6/bin/ruby
5598a9a8b000-5598a9a8d000 rw-p 00286000 00:32 323508                     /home/bork/.rbenv/versions/2.1.6/bin/ruby

所以，我们看到，起始地址 5598a9605000 和 0x5598a9a8f7f0 很像，但并不一样。哪里不一样呢，我们把两个数相减，看看结果是多少：

(gdb) p/x 0x5598a9a8f7f0 - 0x5598a9605000
$4 = 0x48a7f0

你可能会问，这个数是什么？让我们使用 nm 来查看一下程序的符号表。

sudo nm /proc/2983/exe | grep ruby_current_thread
000000000048a7f0 b ruby_current_thread

我们看到了什么？能够看到 0x48a7f0 吗？是的，没错。所以，如果我们想找到程序中一个全局变量的地址，那么只需在符号表中查找变量的名字，然后再加上在 /proc/whatever/maps 中的起始地址，就得到了。

所以现在，我们知道 gdb 做了什么。但是，gdb 实际做的事情更多，让我们跳过直接转到…

解引用指针

(gdb) p ruby_current_thread
$1 = (rb_thread_t *) 0x5598ab3235b0

我们要做的下一件事就是解引用 ruby_current_thread 这一指针。我们想看一下它所指向的地址。为了完成这件事，gdb 会运行大量系统调用比如：

ptrace(PTRACE_PEEKTEXT, 2983, 0x5598a9a8f7f0, [0x5598ab3235b0]) = 0

你是否还记得 0x5598a9a8f7f0 这个地址？gdb 会问：“嘿，在这个地址中的实际内容是什么？”。2983 是我们运行 gdb 这个进程的 ID。gdb 使用 ptrace 这一系统调用来完成这一件事。

好极了！因此，我们可以解引用内存并找出内存地址中存储的内容。有一些有用的 gdb 命令，比如 x/40w 变量 和 x/40b 变量 分别会显示给定地址的 40 个字/字节。

描述结构

一个内存地址中的内容可能看起来像下面这样。可以看到很多字节！

(gdb) x/40b ruby_current_thread
0x5598ab3235b0: 16  -90 55  -85 -104    85  0   0
0x5598ab3235b8: 32  47  50  -85 -104    85  0   0
0x5598ab3235c0: 16  -64 -55 115 -97 127 0   0
0x5598ab3235c8: 0   0   2   0   0   0   0   0
0x5598ab3235d0: -96 -83 -39 115 -97 127 0   0

这很有用，但也不是非常有用！如果你是一个像我一样的人类并且想知道它代表什么，那么你需要更多内容，比如像这样：

(gdb) p *(ruby_current_thread)
$8 = {self = 94114195940880, vm = 0x5598ab322f20, stack = 0x7f9f73c9c010,
    stack_size = 131072, cfp = 0x7f9f73d9ada0, safe_level = 0,    raised_flag = 0,
    last_status = 8, state = 0, waiting_fd = -1, passed_block = 0x0,
    passed_bmethod_me = 0x0, passed_ci = 0x0,    top_self = 94114195612680,
    top_wrapper = 0, base_block = 0x0, root_lep = 0x0, root_svar = 8, thread_id =
    140322820187904,

太好了。现在就更加有用了。gdb 是如何知道这些所有域的，比如 stack_size ？是从 DWARF 得知的。DWARF 是存储额外程序调试数据的一种方式，从而像 gdb 这样的调试器能够工作的更好。它通常存储为二进制的一部分。如果我对我的 Ruby 二进制文件运行 dwarfdump 命令，那么我将会得到下面的输出：

（我已经重新编排使得它更容易理解）

DW_AT_name                  "rb_thread_struct"
DW_AT_byte_size             0x000003e8
DW_TAG_member
  DW_AT_name                  "self"
  DW_AT_type                  <0x00000579>
  DW_AT_data_member_location  DW_OP_plus_uconst 0
DW_TAG_member
  DW_AT_name                  "vm"
  DW_AT_type                  <0x0000270c>
  DW_AT_data_member_location  DW_OP_plus_uconst 8
DW_TAG_member
  DW_AT_name                  "stack"
  DW_AT_type                  <0x000006b3>
  DW_AT_data_member_location  DW_OP_plus_uconst 16
DW_TAG_member
  DW_AT_name                  "stack_size"
  DW_AT_type                  <0x00000031>
  DW_AT_data_member_location  DW_OP_plus_uconst 24
DW_TAG_member
  DW_AT_name                  "cfp"
  DW_AT_type                  <0x00002712>
  DW_AT_data_member_location  DW_OP_plus_uconst 32
DW_TAG_member
  DW_AT_name                  "safe_level"
  DW_AT_type                  <0x00000066>

所以，ruby_current_thread 的类型名为 rb_thread_struct，它的大小为 0x3e8 （即 1000 字节），它有许多成员项，stack_size 是其中之一，在偏移为 24 的地方，它有类型 31 。31 是什么？不用担心，我们也可以在 DWARF 信息中查看。

< 1><0x00000031>    DW_TAG_typedef
                      DW_AT_name                  "size_t"
                      DW_AT_type                  <0x0000003c>
< 1><0x0000003c>    DW_TAG_base_type
                      DW_AT_byte_size             0x00000008
                      DW_AT_encoding              DW_ATE_unsigned
                      DW_AT_name                  "long unsigned int"

所以，stack_size 具有类型 size_t，即 long unsigned int，它是 8 字节的。这意味着我们可以查看该栈的大小。

如果我们有了 DWARF 调试数据，该如何分解：

查看 ruby_current_thread 所指向的内存区域
加上 24 字节来得到 stack_size
读 8 字节（以小端的格式，因为是在 x86 上）
得到答案！

在上面这个例子中是 131072（即 128 kb）。

对我来说，这使得调试信息的用途更加明显。如果我们不知道这些所有变量所表示的额外的元数据，那么我们无法知道存储在 0x5598ab325b0 这一地址的字节是什么。

这就是为什么你可以为你的程序单独安装程序的调试信息，因为 gdb 并不关心从何处获取这些额外的调试信息。

DWARF 令人迷惑

我最近阅读了大量的 DWARF 知识。现在，我使用 libdwarf，使用体验不是很好，这个 API 令人迷惑，你将以一种奇怪的方式初始化所有东西，它真的很慢（需要花费 0.3 秒的时间来读取我的 Ruby 程序的所有调试信息，这真是可笑）。有人告诉我，来自 elfutils 的 libdw 要好一些。

同样，再提及一点，你可以查看 DW_AT_data_member_location 来查看结构成员的偏移。我在 Stack Overflow 上查找如何完成这件事，并且得到这个答案。基本上，以下面这样一个检查开始：

dwarf_whatform(attrs[i], &form, &error);
    if (form == DW_FORM_data1 || form == DW_FORM_data2
        form == DW_FORM_data2 || form == DW_FORM_data4
        form == DW_FORM_data8 || form == DW_FORM_udata) {

继续往前。为什么会有 800 万种不同的 DW_FORM_data 需要检查？发生了什么？我没有头绪。

不管怎么说，我的印象是，DWARF 是一个庞大而复杂的标准（可能是人们用来生成 DWARF 的库稍微不兼容），但是我们有的就是这些，所以我们只能用它来工作。

我能够编写代码并查看 DWARF ，这就很酷了，并且我的代码实际上大多数能够工作。除了程序崩溃的时候。我就是这样工作的。

展开栈路径

在这篇文章的早期版本中，我说过，gdb 使用 libunwind 来展开栈路径，这样说并不总是对的。

有一位对 gdb 有深入研究的人发了大量邮件告诉我，为了能够做得比 libunwind 更好，他们花费了大量时间来尝试如何展开栈路径。这意味着，如果你在程序的一个奇怪的中间位置停下来了，你所能够获取的调试信息又很少，那么你可以对栈做一些奇怪的事情，gdb 会尝试找出你位于何处。

gdb 能做的其他事

我在这儿所描述的一些事请（查看内存，理解 DWARF 所展示的结构）并不是 gdb 能够做的全部事情。阅读 Brendan Gregg 的昔日 gdb 例子，我们可以知道，gdb 也能够完成下面这些事情：

反汇编
查看寄存器内容

在操作程序方面，它可以：

设置断点，单步运行程序
修改内存（这是一个危险行为）

了解 gdb 如何工作使得当我使用它的时候更加自信。我过去经常感到迷惑，因为 gdb 有点像 C，当你输入 ruby_current_thread->cfp->iseq，就好像是在写 C 代码。但是你并不是在写 C 代码。我很容易遇到 gdb 的限制，不知道为什么。

知道使用 DWARF 来找出结构内容给了我一个更好的心智模型和更加正确的期望！这真是极好的！

via: https://jvns.ca/blog/2016/08/10/how-does-gdb-work/

作者：Julia Evans 译者：ucasFL 校对：wxy

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

三步上手 GDB

Julia Evans 发布于 2018-01-25
另请参阅: 软件开发,调试, gdb
评论

调试 C 程序，曾让我很困扰。然而当我之前在写我的操作系统时，我有很多的 Bug 需要调试。我很幸运的使用上了 qemu 模拟器，它允许我将调试器附加到我的操作系统。这个调试器就是 gdb。

我得解释一下，你可以使用 gdb 先做一些小事情，因为我发现初学它的时候真的很混乱。我们接下来会在一个小程序中，设置断点，查看内存。

1、设断点

如果你曾经使用过调试器，那你可能已经会设置断点了。

下面是一个我们要调试的程序（虽然没有任何 Bug）:

#include <stdio.h>
void do_thing() {
    printf("Hi!\n");
}
int main() {
    do_thing();
}

另存为 hello.c. 我们可以使用 dbg 调试它，像这样：

bork@kiwi ~> gcc -g hello.c -o hello
bork@kiwi ~> gdb ./hello

以上是带调试信息编译 hello.c（为了 gdb 可以更好工作），并且它会给我们醒目的提示符，就像这样：

(gdb)

我们可以使用 break 命令设置断点，然后使用 run 开始调试程序。

(gdb) break do_thing 
Breakpoint 1 at 0x4004f8
(gdb) run
Starting program: /home/bork/hello 

Breakpoint 1, 0x00000000004004f8 in do_thing ()

程序暂停在了 do_thing 开始的地方。

我们可以通过 where 查看我们所在的调用栈。

(gdb) where
#0  do_thing () at hello.c:3
#1  0x08050cdb in main () at hello.c:6
(gdb)

2、阅读汇编代码

使用 disassemble 命令，我们可以看到这个函数的汇编代码。棒级了，这是 x86 汇编代码。虽然我不是很懂它，但是 callq 这一行是 printf 函数调用。

(gdb) disassemble do_thing
Dump of assembler code for function do_thing:
   0x00000000004004f4 <+0>:     push   %rbp
   0x00000000004004f5 <+1>:     mov    %rsp,%rbp
=> 0x00000000004004f8 <+4>:     mov    $0x40060c,%edi
   0x00000000004004fd <+9>:     callq  0x4003f0 
   0x0000000000400502 <+14>:    pop    %rbp
   0x0000000000400503 <+15>:    retq

你也可以使用 disassemble 的缩写 disas。

3、查看内存

当调试我的内核时，我使用 gdb 的主要原因是，以确保内存布局是如我所想的那样。检查内存的命令是 examine，或者使用缩写 x。我们将使用x。

通过阅读上面的汇编代码，似乎 0x40060c 可能是我们所要打印的字符串地址。我们来试一下。

(gdb) x/s 0x40060c
0x40060c:        "Hi!"

的确是这样。x/s 中 /s 部分，意思是“把它作为字符串展示”。我也可以“展示 10 个字符”，像这样：

(gdb) x/10c 0x40060c
0x40060c:       72 'H'  105 'i' 33 '!'  0 '\000'        1 '\001'        27 '\033'       3 '\003'        59 ';'
0x400614:       52 '4'  0 '\000'

你可以看到前四个字符是 H、i、! 和 \0，并且它们之后的是一些不相关的东西。

我知道 gdb 很多其他的东西，但是我仍然不是很了解它，其中 x 和 break 让我获得很多。你还可以阅读 do umentation for examining memory。

via: https://jvns.ca/blog/2014/02/10/three-steps-to-learning-gdb/

作者：Julia Evans 译者：Torival 校对：wxy

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

常用 GDB 命令中文速览

Fsf 发布于 2017-09-24
另请参阅: 软件开发,调试, gdb
1 条评论

break -- 在指定的行或函数处设置断点，缩写为 b
info breakpoints -- 打印未删除的所有断点，观察点和捕获点的列表，缩写为 i b
disable -- 禁用断点，缩写为 dis
enable -- 启用断点
clear -- 清除指定行或函数处的断点
delete -- 删除断点，缩写为 d
tbreak -- 设置临时断点，参数同 break，但在程序第一次停住后会被自动删除
watch -- 为表达式（或变量）设置观察点，当表达式（或变量）的值有变化时，暂停程序执行
step -- 单步跟踪，如果有函数调用，会进入该函数，缩写为 s
reverse-step -- 反向单步跟踪，如果有函数调用，会进入该函数
next -- 单步跟踪，如果有函数调用，不会进入该函数，缩写为 n
reverse-next -- 反向单步跟踪，如果有函数调用，不会进入该函数
return -- 使选定的栈帧返回到其调用者
finish -- 执行直到选择的栈帧返回，缩写为 fin
until -- 执行直到达到当前栈帧中当前行后的某一行（用于跳过循环、递归函数调用），缩写为 u
continue -- 恢复程序执行，缩写为 c
print -- 打印表达式 EXP 的值，缩写为 p
x -- 查看内存
display -- 每次程序停止时打印表达式 EXP 的值（自动显示）
info display -- 打印早先设置为自动显示的表达式列表
disable display -- 禁用自动显示
enable display -- 启用自动显示
undisplay -- 删除自动显示项
help -- 打印命令列表（带参数时查找命令的帮助），缩写为 h
attach -- 挂接到已在运行的进程来调试
run -- 启动被调试的程序，缩写为 r
backtrace -- 查看程序调用栈的信息，缩写为 bt
ptype -- 打印类型 TYPE 的定义

break

使用 break 命令（缩写 b）来设置断点。

用法：

break 当不带参数时，在所选栈帧中执行的下一条指令处设置断点。
break <function-name> 在函数体入口处打断点，在 C++ 中可以使用 class::function 或 function(type, ...) 格式来指定函数名。
break <line-number> 在当前源码文件指定行的开始处打断点。
break -N break +N 在当前源码行前面或后面的 N 行开始处打断点，N 为正整数。
break <filename:linenum> 在源码文件 filename 的 linenum 行处打断点。
break <filename:function> 在源码文件 filename 的 function 函数入口处打断点。
break <address> 在程序指令的地址处打断点。
break ... if <cond> 设置条件断点，... 代表上述参数之一（或无参数），cond 为条件表达式，仅在 cond 值非零时暂停程序执行。