大家好！今天，我开始进行我的 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 调试数据，该如何分解：

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

在上面这个例子中是 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中国 荣誉推出

来自我的邮箱：

我写了一个 hello world 小脚本。我如何能调试运行在 Linux 或者类 UNIX 的系统上的 bash shell 脚本呢？

这是 Linux / Unix 系统管理员或新用户最常问的问题。shell 脚本调试可能是一项繁琐的工作（不容易阅读）。调试 shell 脚本有多种方法。

您需要传递 -x 或 -v 参数，以在 bash shell 中浏览每行代码。

让我们看看如何使用各种方法调试 Linux 和 UNIX 上运行的脚本。

-x 选项来调试脚本

用 -x 选项来运行脚本：

$ bash -x script-name
$ bash -x domains.sh

使用 set 内置命令

bash shell 提供调试选项，可以打开或关闭使用 set 命令：

• set -x : 显示命令及其执行时的参数。
• set -v : 显示 shell 输入行作为它们读取的

可以在 shell 脚本本身中使用上面的两个命令：

#!/bin/bash
clear

# turn on debug mode
set -x
for f in *
do
   file $f
done
# turn OFF debug mode
set +x
ls
# more commands

你可以代替 标准释伴 行：

#!/bin/bash

用以下代码（用于调试）：

#!/bin/bash -xv

使用智能调试功能

首先添加一个叫做 _DEBUG 的特殊变量。当你需要调试脚本的时候，设置 _DEBUG 为 on：

_DEBUG="on"

在脚本的开头放置以下函数：

function DEBUG()
{
 [ "$_DEBUG" == "on" ] &&  $@
}

现在，只要你需要调试，只需使用 DEBUG 函数如下：

DEBUG echo "File is $filename"

或者：

DEBUG set -x
Cmd1
Cmd2
DEBUG set +x

当调试完（在移动你的脚本到生产环境之前）设置 _DEBUG 为 off。不需要删除调试行。

_DEBUG="off" # 设置为非 'on' 的任何字符

示例脚本：

#!/bin/bash
_DEBUG="on"
function DEBUG()
{
 [ "$_DEBUG" == "on" ] &&  $@
}

DEBUG echo 'Reading files'
for i in *
do
  grep 'something' $i > /dev/null
  [ $? -eq 0 ] && echo "Found in $i file"
done
DEBUG set -x
a=2
b=3
c=$(( $a + $b ))
DEBUG set +x
echo "$a + $b = $c"

保存并关闭文件。运行脚本如下：

$ ./script.sh

输出：

Reading files
Found in xyz.txt file
+ a=2
+ b=3
+ c=5
+ DEBUG set +x
+ '[' on == on ']'
+ set +x
2 + 3 = 5

现在设置 _DEBUG 为 off（你需要编辑该文件）：

_DEBUG="off"

运行脚本：

$ ./script.sh

输出：

Found in xyz.txt file
2 + 3 = 5

以上是一个简单但非常有效的技术。还可以尝试使用 DEBUG 作为别名而不是函数。

调试 Bash Shell 的常见错误

Bash 或者 sh 或者 ksh 在屏幕上给出各种错误信息，在很多情况下，错误信息可能不提供详细的信息。

跳过在文件上应用执行权限

当你 编写你的第一个 hello world 脚本,您可能会得到一个错误，如下所示：

bash: ./hello.sh: Permission denied

设置权限使用 chmod 命令:

$ chmod +x hello.sh
$ ./hello.sh
$ bash hello.sh

文件结束时发生意外的错误

如果您收到文件结束意外错误消息，请打开脚本文件，并确保它有打开和关闭引号。在这个例子中，echo 语句有一个开头引号，但没有结束引号：

#!/bin/bash

...
....

echo 'Error: File not found
                           ^^^^^^^
                           missing quote

还要确保你检查缺少的括号和大括号 {}：

#!/bin/bash
.....
[ ! -d $DIRNAME ] && { echo "Error: Chroot dir not found"; exit 1;
                                                                    ^^^^^^^^^^^^^
                                                                    missing brace }
...

丢失像 fi，esac，;; 等关键字。

如果你缺少了结尾的关键字，如 fi 或 ;; 你会得到一个错误，如 “XXX 意外”。因此，确保所有嵌套的 if 和 case 语句以适当的关键字结束。有关语法要求的页面。在本例中，缺少 fi：

#!/bin/bash
echo "Starting..."
....
if [ $1 -eq 10 ]
then
   if [ $2 -eq 100 ]
   then
      echo "Do something"
fi

for f in $files
do
  echo $f
done

# 注意 fi 丢失了

在 Windows 或 UNIX 框中移动或编辑 shell 脚本

不要在 Linux 上创建脚本并移动到 Windows。另一个问题是编辑 Windows 10上的 shell 脚本并将其移动到 UNIX 服务器上。这将由于换行符不同而导致命令没有发现的错误。你可以使用下列命令 将 DOS 换行转换为 CR-LF 的Unix/Linux 格式 ：

dos2unix my-script.sh

技巧

技巧 1 - 发送调试信息输出到标准错误

[标准错误] 是默认错误输出设备，用于写所有系统错误信息。因此，将消息发送到默认的错误设备是个好主意：

# 写错误到标准输出
echo "Error: $1 file not found"
#
# 写错误到标准错误（注意 1>&2 在 echo 命令末尾）
#
echo "Error: $1 file not found" 1>&2

技巧 2 - 在使用 vim 文本编辑器时，打开语法高亮

大多数现代文本编辑器允许设置语法高亮选项。这对于检测语法和防止常见错误如打开或关闭引号非常有用。你可以在不同的颜色中看到。这个特性简化了 shell 脚本结构中的编写，语法错误在视觉上截然不同。高亮不影响文本本身的意义，它只为你提示而已。在这个例子中，我的脚本使用了 vim 语法高亮：

!如何调试 Bash Shell 脚本，在 Linux 或者 UNIX 使用 Vim 语法高亮特性]7

技巧 3 - 使用 shellcheck 检查脚本

shellcheck 是一个用于静态分析 shell 脚本的工具。可以使用它来查找 shell 脚本中的错误。这是用 Haskell 编写的。您可以使用这个工具找到警告和建议。你可以看看如何在 Linux 或 类UNIX 系统上安装和使用 shellcheck 来改善你的 shell 脚本，避免错误和高效。

作者：Vivek Gite

作者是 nixCraft 创造者，一个经验丰富的系统管理员和一个练习 Linux 操作系统/ UNIX shell 脚本的教练。他曾与全球客户和各种行业，包括 IT，教育，国防和空间研究，以及非营利部门。关注他的 推特，脸谱网，谷歌+ 。

via: https://www.cyberciti.biz/tips/debugging-shell-script.html

作者：Vivek Gite 译者：zjon 校对：wxy

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

调试 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中国 荣誉推出

一个不幸的事实是，所有的软件都有 bug，一些 bug 会导致系统崩溃。当它出现的时候，它经常会在磁盘上留下一个被称为“ 核心转储 core dump ”的数据文件。该文件包含有关系统崩溃时的相关数据，可能有助于确定发生崩溃的原因。通常开发者要求提供 “ 回溯 backtrace ” 形式的数据，以显示导致崩溃的指令流。开发人员可以使用它来修复 bug 以改进系统。如果系统发生了崩溃，以下是如何轻松生成 回溯 backtrace 的方法。

从使用 coredumpctl 开始

大多数 Fedora 系统使用自动错误报告工具（ABRT）来自动捕获崩溃文件并记录 bug。但是，如果你禁用了此服务或删除了该软件包，则此方法可能会有所帮助。

如果你遇到系统崩溃，请首先确保你运行的是最新的软件。更新通常包含修复程序，这些更新通常含有已经发现的会导致严重错误和崩溃的错误的修复。当你更新后，请尝试重现导致错误的情况。

如果崩溃仍然发生，或者你已经在运行最新的软件，那么可以使用有用的 coredumpctl 工具。此程序可帮助查找和处理崩溃。要查看系统上所有核心转储列表，请运行以下命令：

coredumpctl list

如果你看到比预期长的列表，请不要感到惊讶。有时系统组件在后台默默地崩溃，并自行恢复。快速查找今天的转储的简单方法是使用 -since 选项：

coredumpctl list --since=today

“PID” 列包含用于标识转储的进程 ID。请注意这个数字，因为你会之后再用到它。或者，如果你不想记住它，使用下面的命令将它赋值给一个变量：

MYPID=<PID>

要查看关于核心转储的信息，请使用此命令（使用 $MYPID 变量或替换 PID 编号）：

coredumpctl info $MYPID

安装 debuginfo 包

在核心转储中的数据以及原始代码中的指令之间调试符号转义。这个符号数据可能相当大。与大多数用户运行在 Fedora 系统上的软件包不同，符号以 “debuginfo” 软件包的形式安装。要确定你必须安装哪些 debuginfo 包，请先运行以下命令：

coredumpctl gdb $MYPID

这可能会在屏幕上显示大量信息。最后一行可能会告诉你使用 dnf 安装更多的 debuginfo 软件包。用 sudo 运行该命令以安装：

sudo dnf debuginfo-install <packages...>

然后再次尝试 coredumpctl gdb $MYPID 命令。你可能需要重复执行此操作，因为其他符号会在回溯中展开。

捕获回溯

在调试器中运行以下命令以记录信息：

set logging file mybacktrace.txt
set logging on

你可能会发现关闭分页有帮助。对于长的回溯，这可以节省时间。

set pagination off

现在运行回溯：

thread apply all bt full

现在你可以输入 quit 来退出调试器。mybacktrace.txt 包含可附加到 bug 或问题的追踪信息。或者，如果你正在与某人实时合作，则可以将文本上传到 pastebin。无论哪种方式，你现在可以向开发人员提供更多的帮助来解决问题。

作者简介：

Paul W. Frields

Paul W. Frields 自 1997 年以来一直是 Linux 用户和爱好者，并于 2003 年在 Fedora 发布不久后加入 Fedora。他是 Fedora 项目委员会的创始成员之一，从事文档、网站发布、宣传、工具链开发和维护软件。他于 2008 年 2 月至 2010 年 7 月加入 Red Hat，担任 Fedora 项目负责人，现任红帽公司工程部经理。他目前和妻子和两个孩子住在弗吉尼亚州。

via: https://fedoramagazine.org/file-better-bugs-coredumpctl/

作者：Paul W. Frields 译者：geekpi 校对：wxy

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

我们终于来到这个系列的最后一篇文章！这一次，我将对调试中的一些更高级的概念进行高层的概述：远程调试、共享库支持、表达式计算和多线程支持。这些想法实现起来比较复杂，所以我不会详细说明如何做，但是如果你有问题的话，我很乐意回答有关这些概念的问题。

系列索引

1. 准备环境
2. 断点
3. 寄存器和内存
4. Elves 和 dwarves
5. 源码和信号
6. 源码层逐步执行
7. 源码层断点
8. 调用栈
9. 处理变量
10. 高级主题

远程调试

远程调试对于嵌入式系统或对不同环境进行调试非常有用。它还在高级调试器操作和与操作系统和硬件的交互之间设置了一个很好的分界线。事实上，像 GDB 和 LLDB 这样的调试器即使在调试本地程序时也可以作为远程调试器运行。一般架构是这样的：

调试器是我们通过命令行交互的组件。也许如果你使用的是 IDE，那么在其上有另一个层可以通过机器接口与调试器进行通信。在目标机器上（可能与本机一样）有一个 调试存根 debug stub ，理论上它是一个非常小的操作系统调试库的包装程序，它执行所有的低级调试任务，如在地址上设置断点。我说“在理论上”，因为如今调试存根变得越来越大。例如，我机器上的 LLDB 调试存根大小是 7.6MB。调试存根通过使用一些特定于操作系统的功能（在我们的例子中是 ptrace）和被调试进程以及通过远程协议的调试器通信。

最常见的远程调试协议是 GDB 远程协议。这是一种基于文本的数据包格式，用于在调试器和调试存根之间传递命令和信息。我不会详细介绍它，但你可以在这里进一步阅读。如果你启动 LLDB 并执行命令 log enable gdb-remote packets，那么你将获得通过远程协议发送的所有数据包的跟踪信息。在 GDB 上，你可以用 set remotelogfile <file> 做同样的事情。

作为一个简单的例子，这是设置断点的数据包：

$Z0,400570,1#43

$ 标记数据包的开始。Z0 是插入内存断点的命令。400570 和 1 是参数，其中前者是设置断点的地址，后者是特定目标的断点类型说明符。最后，#43 是校验值，以确保数据没有损坏。

GDB 远程协议非常易于扩展自定义数据包，这对于实现平台或语言特定的功能非常有用。

共享库和动态加载支持

调试器需要知道被调试程序加载了哪些共享库，以便它可以设置断点、获取源代码级别的信息和符号等。除查找被动态链接的库之外，调试器还必须跟踪在运行时通过 dlopen 加载的库。为了达到这个目的，动态链接器维护一个 交汇结构体。该结构体维护共享库描述符的链表，以及一个指向每当更新链表时调用的函数的指针。这个结构存储在 ELF 文件的 .dynamic 段中，在程序执行之前被初始化。

一个简单的跟踪算法：

• 追踪程序在 ELF 头中查找程序的入口（或者可以使用存储在 /proc/<pid>/aux 中的辅助向量）。
• 追踪程序在程序的入口处设置一个断点，并开始执行。
• 当到达断点时，通过在 ELF 文件中查找 .dynamic 的加载地址找到交汇结构体的地址。
• 检查交汇结构体以获取当前加载的库的列表。
• 链接器更新函数上设置断点。
• 每当到达断点时，列表都会更新。
• 追踪程序无限循环，继续执行程序并等待信号，直到追踪程序信号退出。

我给这些概念写了一个小例子，你可以在这里找到。如果有人有兴趣，我可以将来写得更详细一点。

表达式计算

表达式计算是程序的一项功能，允许用户在调试程序时对原始源语言中的表达式进行计算。例如，在 LLDB 或 GDB 中，可以执行 print foo() 来调用 foo 函数并打印结果。

根据表达式的复杂程度，有几种不同的计算方法。如果表达式只是一个简单的标识符，那么调试器可以查看调试信息，找到该变量并打印出该值，就像我们在本系列最后一部分中所做的那样。如果表达式有点复杂，则可能将代码编译成中间表达式 （IR） 并解释来获得结果。例如，对于某些表达式，LLDB 将使用 Clang 将表达式编译为 LLVM IR 并将其解释。如果表达式更复杂，或者需要调用某些函数，那么代码可能需要 JIT 到目标并在被调试者的地址空间中执行。这涉及到调用 mmap 来分配一些可执行内存，然后将编译的代码复制到该块并执行。LLDB 通过使用 LLVM 的 JIT 功能来实现。

如果你想更多地了解 JIT 编译，我强烈推荐 Eli Bendersky 关于这个主题的文章。

多线程调试支持

本系列展示的调试器仅支持单线程应用程序，但是为了调试大多数真实程序，多线程支持是非常需要的。支持这一点的最简单的方法是跟踪线程的创建，并解析 procfs 以获取所需的信息。

Linux 线程库称为 pthreads。当调用 pthread_create 时，库会使用 clone 系统调用来创建一个新的线程，我们可以用 ptrace 跟踪这个系统调用（假设你的内核早于 2.5.46）。为此，你需要在连接到调试器之后设置一些 ptrace 选项：

ptrace(PTRACE_SETOPTIONS, m_pid, nullptr, PTRACE_O_TRACECLONE);

现在当 clone 被调用时，该进程将收到我们的老朋友 SIGTRAP 信号。对于本系列中的调试器，你可以将一个例子添加到 handle_sigtrap 来处理新线程的创建：

case (SIGTRAP | (PTRACE_EVENT_CLONE << 8)):
    //get the new thread ID
    unsigned long event_message = 0;
    ptrace(PTRACE_GETEVENTMSG, pid, nullptr, message);

    //handle creation
    //...

一旦收到了，你可以看看 /proc/<pid>/task/ 并查看内存映射之类来获得所需的所有信息。

GDB 使用 libthread_db，它提供了一堆帮助函数，这样你就不需要自己解析和处理。设置这个库很奇怪，我不会在这展示它如何工作，但如果你想使用它，你可以去阅读这个教程。

多线程支持中最复杂的部分是调试器中线程状态的建模，特别是如果你希望支持不间断模式或当你计算中涉及不止一个 CPU 的某种异构调试。

最后！

呼！这个系列花了很长时间才写完，但是我在这个过程中学到了很多东西，我希望它是有帮助的。如果你有关于调试或本系列中的任何问题，请在 Twitter @TartanLlama或评论区联系我。如果你有想看到的其他任何调试主题，让我知道我或许会再发其他的文章。

via: https://blog.tartanllama.xyz/writing-a-linux-debugger-advanced-topics/

作者：Simon Brand 译者：geekpi 校对：wxy

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

变量是偷偷摸摸的。有时，它们会很高兴地呆在寄存器中，但是一转头就会跑到堆栈中。为了优化，编译器可能会完全将它们从窗口中抛出。无论变量在内存中的如何移动，我们都需要一些方法在调试器中跟踪和操作它们。这篇文章将会教你如何处理调试器中的变量，并使用 libelfin 演示一个简单的实现。

系列文章索引

1. 准备环境
2. 断点
3. 寄存器和内存
4. ELF 和 DWARF
5. 源码和信号
6. 源码级逐步执行
7. 源码级断点
8. 堆栈展开
9. 处理变量
10. 高级话题

在开始之前，请确保你使用的 libelfin 版本是我分支上的 fbreg。这包含了一些 hack 来支持获取当前堆栈帧的基址并评估位置列表，这些都不是由原生的 libelfin 提供的。你可能需要给 GCC 传递 -gdwarf-2 参数使其生成兼容的 DWARF 信息。但是在实现之前，我将详细说明 DWARF 5 最新规范中的位置编码方式。如果你想要了解更多信息，那么你可以从这里获取该标准。

DWARF 位置

某一给定时刻的内存中变量的位置使用 DW_AT_location 属性编码在 DWARF 信息中。位置描述可以是单个位置描述、复合位置描述或位置列表。

• 简单位置描述：描述了对象的一个​​连续的部分（通常是所有部分）的位置。简单位置描述可以描述可寻址存储器或寄存器中的位置，或缺少位置（具有或不具有已知值）。比如，DW_OP_fbreg -32： 一个整个存储的变量 - 从堆栈帧基址开始的32个字节。
• 复合位置描述：根据片段描述对象，每个对象可以包含在寄存器的一部分中或存储在与其他片段无关的存储器位置中。比如， DW_OP_reg3 DW_OP_piece 4 DW_OP_reg10 DW_OP_piece 2：前四个字节位于寄存器 3 中，后两个字节位于寄存器 10 中的一个变量。

• 位置列表：描述了具有有限生存期或在生存期内更改位置的对象。比如：

  • <loclist with 3 entries follows>

    • [ 0]<lowpc=0x2e00><highpc=0x2e19>DW_OP_reg0
    • [ 1]<lowpc=0x2e19><highpc=0x2e3f>DW_OP_reg3
    • [ 2]<lowpc=0x2ec4><highpc=0x2ec7>DW_OP_reg2
  • 根据程序计数器的当前值，位置在寄存器之间移动的变量。

根据位置描述的种类，DW_AT_location 以三种不同的方式进行编码。exprloc 编码简单和复合的位置描述。它们由一个字节长度组成，后跟一个 DWARF 表达式或位置描述。loclist 和 loclistptr 的编码位置列表，它们在 .debug_loclists 部分中提供索引或偏移量，该部分描述了实际的位置列表。

DWARF 表达式

使用 DWARF 表达式计算变量的实际位置。这包括操作堆栈值的一系列操作。有很多 DWARF 操作可用，所以我不会详细解释它们。相反，我会从每一个表达式中给出一些例子，给你一个可用的东西。另外，不要害怕这些；libelfin 将为我们处理所有这些复杂性。

• 字面编码

  • DW_OP_lit0、DW_OP_lit1……DW_OP_lit31

    • 将字面量压入堆栈

  • DW_OP_addr <addr>

    • 将地址操作数压入堆栈

  • DW_OP_constu <unsigned>

    • 将无符号值压入堆栈

• 寄存器值

  • DW_OP_fbreg <offset>

    • 压入在堆栈帧基址找到的值，偏移给定值

  • DW_OP_breg0、DW_OP_breg1…… DW_OP_breg31 <offset>

    • 将给定寄存器的内容加上给定的偏移量压入堆栈

• 堆栈操作

  • DW_OP_dup

    • 复制堆栈顶部的值

  • DW_OP_deref

    • 将堆栈顶部视为内存地址，并将其替换为该地址的内容

• 算术和逻辑运算

  • DW_OP_and

    • 弹出堆栈顶部的两个值，并压回它们的逻辑 AND

  • DW_OP_plus

    • 与 DW_OP_and 相同，但是会添加值

• 控制流操作

  • DW_OP_le、DW_OP_eq、DW_OP_gt 等

    • 弹出前两个值，比较它们，并且如果条件为真，则压入 1，否则为 0

  • DW_OP_bra <offset>

    • 条件分支：如果堆栈的顶部不是 0，则通过 offset 在表达式中向后或向后跳过

• 输入转化

  • DW_OP_convert <DIE offset>

    • 将堆栈顶部的值转换为不同的类型，它由给定偏移量的 DWARF 信息条目描述

• 特殊操作

  • DW_OP_nop

    • 什么都不做！

DWARF 类型

DWARF 类型的表示需要足够强大来为调试器用户提供有用的变量表示。用户经常希望能够在应用程序级别进行调试，而不是在机器级别进行调试，并且他们需要了解他们的变量正在做什么。

DWARF 类型与大多数其他调试信息一起编码在 DIE 中。它们可以具有指示其名称、编码、大小、字节等的属性。无数的类型标签可用于表示指针、数组、结构体、typedef 以及 C 或 C++ 程序中可以看到的任何其他内容。

以这个简单的结构体为例：

struct test{
    int i;
    float j;
    int k[42];
    test* next;
};

这个结构体的父 DIE 是这样的：

< 1><0x0000002a>    DW_TAG_structure_type
                      DW_AT_name                  "test"
                      DW_AT_byte_size             0x000000b8
                      DW_AT_decl_file             0x00000001 test.cpp
                      DW_AT_decl_line             0x00000001

上面说的是我们有一个叫做 test 的结构体，大小为 0xb8，在 test.cpp 的第 1 行声明。接下来有许多描述成员的子 DIE。

< 2><0x00000032>      DW_TAG_member
                        DW_AT_name                  "i"
                        DW_AT_type                  <0x00000063>
                        DW_AT_decl_file             0x00000001 test.cpp
                        DW_AT_decl_line             0x00000002
                        DW_AT_data_member_location  0
< 2><0x0000003e>      DW_TAG_member
                        DW_AT_name                  "j"
                        DW_AT_type                  <0x0000006a>
                        DW_AT_decl_file             0x00000001 test.cpp
                        DW_AT_decl_line             0x00000003
                        DW_AT_data_member_location  4
< 2><0x0000004a>      DW_TAG_member
                        DW_AT_name                  "k"
                        DW_AT_type                  <0x00000071>
                        DW_AT_decl_file             0x00000001 test.cpp
                        DW_AT_decl_line             0x00000004
                        DW_AT_data_member_location  8
< 2><0x00000056>      DW_TAG_member
                        DW_AT_name                  "next"
                        DW_AT_type                  <0x00000084>
                        DW_AT_decl_file             0x00000001 test.cpp
                        DW_AT_decl_line             0x00000005
                        DW_AT_data_member_location  176(as signed = -80)

每个成员都有一个名称、一个类型（它是一个 DIE 偏移量）、一个声明文件和行，以及一个指向其成员所在的结构体的字节偏移。其类型指向如下。

< 1><0x00000063>    DW_TAG_base_type
                      DW_AT_name                  "int"
                      DW_AT_encoding              DW_ATE_signed
                      DW_AT_byte_size             0x00000004
< 1><0x0000006a>    DW_TAG_base_type
                      DW_AT_name                  "float"
                      DW_AT_encoding              DW_ATE_float
                      DW_AT_byte_size             0x00000004
< 1><0x00000071>    DW_TAG_array_type
                      DW_AT_type                  <0x00000063>
< 2><0x00000076>      DW_TAG_subrange_type
                        DW_AT_type                  <0x0000007d>
                        DW_AT_count                 0x0000002a
< 1><0x0000007d>    DW_TAG_base_type
                      DW_AT_name                  "sizetype"
                      DW_AT_byte_size             0x00000008
                      DW_AT_encoding              DW_ATE_unsigned
< 1><0x00000084>    DW_TAG_pointer_type
                      DW_AT_type                  <0x0000002a>

如你所见，我笔记本电脑上的 int 是一个 4 字节的有符号整数类型，float是一个 4 字节的浮点数。整数数组类型通过指向 int 类型作为其元素类型，sizetype（可以认为是 size_t）作为索引类型，它具有 2a 个元素。 test * 类型是 DW_TAG_pointer_type，它引用 test DIE。

实现简单的变量读取器

如上所述，libelfin 将为我们处理大部分复杂性。但是，它并没有实现用于表示可变位置的所有方法，并且在我们的代码中处理这些将变得非常复杂。因此，我现在选择只支持 exprloc。请根据需要添加对更多类型表达式的支持。如果你真的有勇气，请提交补丁到 libelfin 中来帮助完成必要的支持！

处理变量主要是将不同部分定位在存储器或寄存器中，读取或写入与之前一样。为了简单起见，我只会告诉你如何实现读取。

首先我们需要告诉 libelfin 如何从我们的进程中读取寄存器。我们创建一个继承自 expr_context 的类并使用 ptrace 来处理所有内容：

class ptrace_expr_context : public dwarf::expr_context {
public:
    ptrace_expr_context (pid_t pid) : m_pid{pid} {}

    dwarf::taddr reg (unsigned regnum) override {
        return get_register_value_from_dwarf_register(m_pid, regnum);
    }

    dwarf::taddr pc() override {
        struct user_regs_struct regs;
        ptrace(PTRACE_GETREGS, m_pid, nullptr, &regs);
        return regs.rip;
    }

    dwarf::taddr deref_size (dwarf::taddr address, unsigned size) override {
        //TODO take into account size
        return ptrace(PTRACE_PEEKDATA, m_pid, address, nullptr);
    }

private:
    pid_t m_pid;
};

读取将由我们 debugger 类中的 read_variables 函数处理：

void debugger::read_variables() {
    using namespace dwarf;

    auto func = get_function_from_pc(get_pc());

    //...
}

我们上面做的第一件事是找到我们目前进入的函数，然后我们需要循环访问该函数中的条目来寻找变量：

    for (const auto& die : func) {
        if (die.tag == DW_TAG::variable) {
            //...
        }
    }

我们通过查找 DIE 中的 DW_AT_location 条目获取位置信息：

            auto loc_val = die[DW_AT::location];

接着我们确保它是一个 exprloc，并请求 libelfin 来评估我们的表达式：

            if (loc_val.get_type() == value::type::exprloc) {
                ptrace_expr_context context {m_pid};
                auto result = loc_val.as_exprloc().evaluate(&context);

现在我们已经评估了表达式，我们需要读取变量的内容。它可以在内存或寄存器中，因此我们将处理这两种情况：

                switch (result.location_type) {
                case expr_result::type::address:
                {
                    auto value = read_memory(result.value);
                    std::cout << at_name(die) << " (0x" << std::hex << result.value << ") = "
                              << value << std::endl;
                    break;
                }

                case expr_result::type::reg:
                {
                    auto value = get_register_value_from_dwarf_register(m_pid, result.value);
                    std::cout << at_name(die) << " (reg " << result.value << ") = "
                              << value << std::endl;
                    break;
                }

                default:
                    throw std::runtime_error{"Unhandled variable location"};
                }

你可以看到，我根据变量的类型，打印输出了值而没有解释。希望通过这个代码，你可以看到如何支持编写变量，或者用给定的名字搜索变量。

最后我们可以将它添加到我们的命令解析器中：

    else if(is_prefix(command, "variables")) {
        read_variables();
    }

测试一下

编写一些具有一些变量的小功能，不用优化并带有调试信息编译它，然后查看是否可以读取变量的值。尝试写入存储变量的内存地址，并查看程序改变的行为。

已经有九篇文章了，还剩最后一篇！下一次我会讨论一些你可能会感兴趣的更高级的概念。现在你可以在这里找到这个帖子的代码。

via: https://blog.tartanllama.xyz/writing-a-linux-debugger-variables/

作者：Simon Brand 译者：geekpi 校对：wxy

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